Blueprintr User Guide

Blueprintr publishes documentation built around a diagram rather than beside one. You draw the system, attach the detail to the parts of the drawing it describes, and publish the result as one thing.

Pick a starting point

What the pieces are

A blueprint is the published unit: one or more diagram tabs, the prose around them, and the files they reference. A stratum is detail bound to a single shape, opened by clicking that shape. Vellum is the diagram editor. A folium is a multi-page documentation site. This guide is one.

Read the first two pages if you are in a hurry.

One complete pass through Blueprintr, from registration to a published page.

Walk it as slides first. Five screens, with the control under discussion ringed on each:

Then the same loop in writing:

Your blueprint is now at blueprintr.io/<your-handle>/<slug>.

What to do next

Blueprintr uses a small number of made-up words. They are all names for ordinary things.

How they relate

You draw in Vellum. The drawing becomes a diagram tab inside a blueprint. Shapes on that diagram carry strata. The blueprint is filed in a portfolio and published once. The same content is then readable on your profile, in an Atrium, embedded in a folium, or presented as a podium.

Compendium and Continuum

Compendium is the template library. Continuum connects a diagram to a live cloud account so the drawing can be checked against what exists.

The blueprint editor has three steps. Move between them in any order; only publishing is gated.

Step 1: Content

A blueprint is a set of tabs. The first is always a diagram; after that, add Rich Text tabs for prose, Raw tabs for code or config, and further diagram tabs.

Use tabs for separate views of the same subject: a logical view and a physical view, or one per environment. Do not use them as chapters of an essay; that is what strata and foliums are for.

Step 2: Resources & Strata

Everything that sits alongside the diagram:

Step 3: Publish

Tags are suggested from your content and can be edited. They drive discovery and the related-content rail.

Visibility is one of three values:

Pre-flight checks run last. They catch the things that make a published blueprint look unfinished: an empty canvas, a tab with no content, a missing title. Publishing is blocked until they pass.

Everything you create is owned by exactly one of three things: you, a team, or an organisation. The choice sets who can edit it, where it appears, and what its published URL looks like.

Choosing at creation

The wizard's Publish to selector sets the owner. It is seeded from whichever workspace you were looking at when you started.

Moving something later

Reassigning an owner changes the published URL. Filing the same blueprint in a different portfolio changes neither ownership nor the URL.

The dashboard is scoped to one workspace at a time. The switcher at the top of the left rail decides whether you are looking at your own content, a team's, or an organisation's. It also seeds the Publish to selector when you start something new.

If you cannot find a blueprint, check that switcher. It may belong to a different workspace.

The rail

Customize sidebar at the foot of the rail decides which of these are pinned, so your own rail may show fewer of them.

The three buttons

Create blueprint opens the three-step editor. Draw with Vellum creates a standalone diagram with no blueprint around it. Import opens the import wizard for content coming from Confluence, Notion, SharePoint, or a set of files.

A blueprint is one published thing made of several parts. Only the first is mandatory.

Why a diagram is mandatory

A blueprint without a diagram is a document, and there are better tools for documents. Requiring one in first position means every blueprint opens with a picture, and every reader gets orientation before prose.

Tabs

Tabs are separate views of the same subject, not chapters: a logical view and a physical view, one per environment, or the architecture and the sequence.

Six kinds are available:

Open the editor with Create blueprint on the dashboard, or by editing an existing blueprint. The three steps can be visited in any order; only publishing is gated.

1. Content

Title and tabs. The first tab must be a diagram.

The canvas fills most of the step. The engine menu switches between Vellum, draw.io, Excalidraw and Mermaid; Vellum is the default unless you have changed it in Settings → General.

Right-clicking a shape offers Add Stratum… here, so detail can be written before the diagram is finished.

2. Resources & Strata

Everything alongside the diagram: strata, further diagrams that are not tabs, and uploaded files organised into folders.

Skippable on a first pass.

3. Publish

Rich text in Blueprintr is markdown plus a component library. The same components work in a blueprint's Rich Text tabs, in a stratum's Rich tab, and on every folium page, including this one.

Every component is written as a blockquote whose first line is a marker. That format survives the visual editor, and degrades to a readable quote in any plain markdown renderer.

Callouts

> [!NOTE]
> Ordinary supporting detail.

Available kinds: NOTE, TIP, IMPORTANT, INFO, FAQ, TLDR, QUOTE.

Procedures

> [!STEPS]
>
> === Install the CLI
>
> Run the installer.
>
> === Authenticate
>
> Then sign in.

Steps are numbered automatically. A plain ordered list inside [!STEPS] works too.

Panels and grids

=== Label on its own line separates panels in every multi-panel component.

API and reference

> [!FIELDS]
>
> > [!FIELD userId|string|required]
> >
> > The caller's user id.
>
> > [!RESPONSE createdAt|datetime]
> >
> > When the record was written.

Inline pieces

Audience splitting

> [!VISIBILITY agents]
>
> Notes for an AI agent reading this page.

Content marked agents is removed before the HTML reaches a human reader, and content marked humans is removed for an agent. Use it for machine-readable hints you do not want on the page.

Embeds

Diagram embeds can be resized by dragging their corners; the size is written back into the markdown.

Tabs run across the top of a published blueprint and are the reader's main navigation. The first is always a diagram.

Adding

Add tab in step 1 offers the six kinds. The choice is fixed once content exists in the tab.

Naming

Tab names are the labels on the strip. Short nouns work: Logical, Physical, Runtime, Data. Avoid restating the blueprint title in every tab.

Ordering

Drag to reorder. The first tab must remain a diagram: the editor will not let you drag a prose tab into first position.

Engines

Each diagram tab has its own engine, and a blueprint can mix them: a Vellum context diagram, a Mermaid sequence diagram, and an imported draw.io network diagram in one document. draw.io, Excalidraw and Mermaid covers the non-Vellum engines.

Limits

There is a hard ceiling on tabs per blueprint. If you are close to it, split the content into several blueprints in a portfolio, or move it into a folium.

A published blueprint has a place to talk about it, and a way to propose changing it.

Discussion

The Discussion tab holds topics. Anyone who can read the blueprint can open one; replies thread underneath. It is for questions and context: "why is this queue here", "is this still true after the migration".

Discussion never changes the blueprint.

Change requests

A change request proposes an edit to a blueprint you do not have edit rights on. It is the analogue of opening a pull request against someone else's repository.

Reviews

Organisations can require review before publishing. Where that is configured, a publish becomes a submission and the blueprint waits in Reviews until someone with the right role approves it.

Step 2 of the editor holds a column view for everything uploaded alongside the blueprint: images used in prose, attachments readers can download, and diagram sources.

Folders

Files have a folder path rather than sitting in actual directories, so reorganising never breaks a reference. Create a folder, drag files into it, rename freely.

Referencing a file

An uploaded image is inserted into rich text as an ordinary markdown image; other files become links. Both keep resolving after a move, a rename, and a publish.

A file's URL is keyed on the file's id, not the blueprint's, because publishing reparents a draft's files onto the published blueprint and deletes the draft row. A blueprint id baked into a link would dangle after one publish. The URL also re-resolves storage on every request, so a reference that outlives a signed URL's expiry still works.

Visibility

Ceilings

The 5 MB document cap exists because the request body ceiling above it is 6 MB. A document that passed would fail on the way out.

Quotas

Storage is counted per owner, not per blueprint:

The total counts diagram documents and their thumbnails, externalised diagram images, attachments, blueprint asset files and custom icon packs. A draft and its published sibling share the same stored objects, so a published blueprint is not charged twice.

It does not yet count inline markdown, version snapshots, templates, folium assets, podium assets, avatars and covers. The figure therefore runs below actual usage.

Both figures are shown on billing and usage.

Status and Visibility are independent properties. Status is whether the blueprint has ever been published. Visibility is who may read it once it has been.

Status

A new blueprint is a draft: only you and anyone you share it with can see it, whatever its visibility says. Publishing makes the current content the live version. Editing afterwards creates a new draft against that version, so readers keep seeing the last published state until you publish again.

Visibility

Pre-flight checks

Publishing is blocked until these pass:

• an empty diagram canvas
• a tab with no content
• a missing title
• a rich tab containing only whitespace

Each finding links to the thing to fix.

Ownership and classification

Publish to sets the owner: you, a team, or an organisation, as described in where content lives.

Organisations can apply a classification that constrains what visibility a blueprint is allowed to have. Where a classification is set, you cannot publish above the ceiling it defines.

Publishing writes a version. The History tab lists them, newest first.

What a version holds

A complete frozen copy of the blueprint at publish time: tabs, diagram sources, strata and files. It is not a diff, so an old version renders as it did rather than being reconstructed.

Comparing

The panel offers four views of a version:

Diffing against the previous version answers "what did that publish change". Compare with this version sets an older baseline and answers "what has changed since the release we shipped against".

Restoring

History is append-only, so the state you replaced is itself still a version. A restore you regret is undone by restoring the one before it.

Pinning

An embed can be pinned to a version rather than tracking the latest. A blueprint quoted in a report then stays as it was on the day it was quoted.

Analytics is reported at two scopes from the same data: the Analytics tab on the blueprint itself, and Dashboard → Analytics, across everything you can see in the current workspace.

Who can see it

Analytics is owner data, and access is narrower than for the tabs beside it: the author, anyone who can edit the blueprint (team and org managers, plus explicit ACL-edit), or a moderator. A reader who can open the blueprint cannot open its analytics.

What is counted

Counts only. No reader is identified: the session is hashed, and nothing in the panel resolves to a person.

Traffic sources

On-platform arrivals are attributed to the surface that produced them, in the platform's own vocabulary:

The breakdown shows whether a blueprint is found because people go looking for it, or only because you sent them the link.

Embeds

Views through an embed are counted and attributed to the embedding page.

Tags are set on the Publish step. They drive search ranking, the related-content rail, and the public tag pages.

The three layers

Discovery runs on a three-level taxonomy.

A reader picks broad categories and sub-interests, and your tags are matched against them. The match fills a signed-in reader's dashboard, reaching people who never searched for the blueprint.

Suggestions

At publish time a classifier proposes tags from your content, using embeddings and a language model, each with a confidence score. You accept the right ones and delete the rest.

Every attachment records how it got there:

An unaccepted suggestion is not attached.

Checking what stuck

list_blueprint_tags on the MCP server returns each tag with its slug, label, provenance and taxonomy placement.

set_blueprint_tags replaces the whole set, so read before you write.

The Compendium is the template library. A template is a complete blueprint, including its diagram, strata and prose, that you copy and edit.

Three scopes

What you see in the Compendium comes from three places:

Using one

Pick a template and create from it. You get a private draft: a blueprint draft filed into your own portfolios, or for a diagram template, a private vellum in your Drafts portfolio. The original is untouched either way.

Creating from a template never publishes anything, however public the template was.

Making one

Any blueprint you can edit can become a template from its admin menu, and so can a standalone Vellum diagram, which gives a diagram-only starting point rather than a whole blueprint.

Sharing it beyond yourself depends on the permissions your role gives you.

A template is a snapshot

Editing the source blueprint afterwards does not change the template, and editing a copy does not change the source. get_template reports what a snapshot contains before you commit to it.

Vellum is Blueprintr's diagram editor and the default engine for any new diagram. It runs inside the blueprint editor, as a standalone diagram, and as a desktop app.

Two layers

Every shape sits on one of two layers.

Press W to switch which layer you draw on. The pills at the bottom left control which layers you can see, so you can hide the noise without deleting it.

Press Shift Cmd P to promote a Notes item to the Blueprint layer.

Getting around

Cmd K searches every shape, icon and command.

Cmd 0 resets the view; Cmd 1 fits everything to the viewport.

Tools

Shape kinds

The inspector

Selecting a shape opens the inspector on the right: stroke and fill, fill opacity, line weight, dash, prism, corner roundness and opacity under Appearance; font, size and text colour under Typography; then the shape's Label and Body text.

Containers

A container owns its children. Drag the container and everything inside moves; resize it and the children stay put. Nesting is unlimited. Use one container per boundary, whether that boundary is a VPC, a team, or a process stage.

Press 8 for the container tool, then drop shapes inside it.

Connectors

Hover a shape and drag from its edge to draw a connector to another shape. The endpoints stay attached when either shape moves.

Routing is straight, curved or orthogonal per connector.

Moving and resizing

Fills and strokes

Shapes take a fill and a stroke from a named palette rather than arbitrary hex. Palette colours are theme-aware, so a diagram drawn in light mode stays legible in dark mode.

Make colour mean something

Use each hue for exactly one category, consistently. Give data stores one colour, external systems another, and the subject of the diagram a third. A rainbow of shapes where colour means nothing is harder to read than no colour at all.

Fidelity

Fidelity controls how hand-drawn the rendering looks, from a clean technical line to a sketchier stroke. It is a per-shape property with a document default.

Sketchy reads as "draft, still moving". Clean reads as "this is the answer". Keep one fidelity per diagram.

Theme

Shift Cmd D toggles the editor between light and dark. Check your diagram in both before publishing, to catch a fill that only works in one.

Vellum ships with vendor icon packs covering the major cloud providers and a wide range of software and infrastructure vendors.

Finding an icon

Cmd K searches icons alongside shapes and commands. Type what the thing is, such as "lambda", "postgres" or "firewall", and insert the match.

Your own SVGs

Drag .svg files from your computer onto the canvas. They are added as icons and saved to your personal library, so they are available in every diagram afterwards.

Libraries

Dashboard → Libraries controls which packs are enabled for your workspace and holds the icons you have added yourself. Organisations can curate the list so a team's diagrams stay visually consistent.

Licensing

Vendor marks are supplied under the terms their owners publish, and those terms vary. Check licences before using a vendor mark in material you distribute outside Blueprintr.

Vellum is the default engine. Three others are available from the engine menu on any diagram tab, and a blueprint can mix them.

What you give up

Strata bind to shapes on any engine, so layered detail works everywhere. The difference is elsewhere:

Changing your default

Settings → General sets which engine new diagrams start in.

Vellum diagrams saved to the cloud can be edited by several people at once. Cursors, selections and edits appear live.

Roles

Access is per-diagram, and the role decides what someone can do.

A reviewer with the Read role can point at things and leave notes without any risk of moving your shapes. Notes left by others are badged with the author's name and colour.

Inviting

Open the collaboration panel from the editor. Each diagram has two invite links, one granting write and one granting read. Share the one you mean.

Guests

Someone who is not signed in and follows an invite lands in a lobby rather than the canvas. The owner sees them queued and clicks Allow or Deny. Signed-in users skip the lobby.

Where it works

Live collaboration is a Vellum feature. draw.io, Excalidraw and Mermaid tabs are single-editor.

blueprintr.io/download offers two different builds.

macOS, Windows and Linux.

Blueprintr Vellum

The same editor as the web version, without browser chrome, with its own dock icon and smoother rendering on high-refresh displays.

Sign-in is handed to your normal browser rather than asked for in the window, so you authenticate where your password manager already works and the browser hands the session back.

There is no separate desktop file type and no separate account. Open the same diagram in the browser and you see the same content, including anything a collaborator changed while you were in the app.

The app updates itself and prompts you when a new version is ready.

Vellum Core

Core is the drawing canvas without the rest of Blueprintr. Diagrams are files on your machine.

Which to install

Install Blueprintr Vellum if you have an account. Install Core when the work cannot leave the machine, or when you want a diagram tool with no service behind it.

On macOS the modifier is Cmd; elsewhere it is Ctrl. The editor's Tips & shortcuts button shows the same list with the right keys for your platform.

Find and select

Transform

Layers

View

Tools

A stratum is a block of detail attached to one shape. The reader clicks the shape and the detail opens beside it, with the diagram still on screen.

In a long page of prose the reader has to work out which paragraph belongs to which box. A stratum removes the guess: the detail has exactly one owner, and the owner is the thing they are already looking at.

What a stratum holds

A stratum is a set of tabs, and each tab has a kind. One stratum can mix them: an overview in Rich, the config it describes in Raw, and a Subdiagram that opens the box up.

Adding one

Right-click the shape and choose Add Stratum…. The modal opens already bound to that shape.

Right-click the same shape later and the item reads Edit Stratum…. Shapes carrying a stratum are marked on the canvas.

What readers get

Hovering a marked shape for half a second shows a preview card with the stratum's name and its opening lines. Clicking opens it in a window that moves and resizes by its corners, or docks to a panel down the right-hand side at half the viewport width.

Readers can leave the panel open and work through several strata in turn while the diagram stays put.

From the shape

Right-click a shape on any diagram in the blueprint and choose Add Stratum…. The stratum is created and anchored to that shape as soon as you choose it, so the modal opens on a stratum that already exists. Close it without typing and the stratum stays; fill in the content later if you would rather keep drawing.

This is the normal path. It is available in step 1 of the editor as well as step 2, so you can write detail while the diagram is still taking shape.

Once a shape carries a stratum, the same menu reads Edit Stratum… and the shape is marked on the canvas.

From the Resources & Strata step

Step 2 lists every stratum in the blueprint. Add Stratum here creates one that is not yet bound to anything; use the link picker to point it at a shape afterwards.

Use it when you are writing several strata in one sitting and binding them later, or when the detail exists before the drawing does.

From a diagram embedded in prose

A diagram inside a Rich Text tab has its own kebab menu with Add Stratum…. Strata bound to an embedded diagram behave exactly like those on a tab canvas.

Inside the editor

A stratum has a name, and one or more tabs. The name is what readers see on the hover preview and in the window's title bar, so write it as a label rather than a sentence.

Add a tab with Add tab and choose its kind. Reorder tabs by dragging; the first is what opens by default.

The Anchor row shows what the stratum is attached to. Change repoints it, Remove detaches it, and + Add anchors the same stratum to another shape, for detail that belongs to two places on a drawing.

Deleting

Deleting a stratum that something links to leaves those links dangling, and the reader sees them as missing. The delete confirmation lists the referrers first: inline stratum: links, linked callouts, and any stratum whose diagram link points inside the one you are removing. Read that list before confirming.

Every tab in a stratum has a kind, chosen when you add it. One stratum can mix them freely.

Choosing

A stratum is always bound to a shape on a surface. It can also be linked to from prose.

Binding with the picker

The link picker opens the diagram in a read-only pick view. Click the shape you mean and the stratum binds to it.

The surface can be a diagram tab's own canvas, or a diagram embedded inside rich or raw content elsewhere in the blueprint. The binding is what lets a reader's click resolve to the right stratum when a blueprint holds several diagrams.

Linking from prose

Markdown links accept a stratum: scheme:

[see the auth flow](stratum:clx1a2b3c4)

Following the link opens that stratum, the same as clicking its shape.

Callouts take the same target, so a whole note becomes the link:

> [!NOTE|stratum:clx1a2b3c4] Where this is enforced

Legacy links

Content written before strata were renamed used a stage: prefix. Blueprintr still reads stage: links and writes new ones as stratum:, so old blueprints keep working with no migration.

Strata stay out of the way until a reader wants them.

Marked shapes

A shape carrying a stratum is marked on the canvas. The mark is the only change to the drawing, and a reader who never clicks one still sees the complete diagram.

Hover

Hovering a marked shape for half a second shows a preview card with the stratum's name and its opening lines. Enough to decide whether to click.

The window

Clicking opens the stratum in a floating window. Readers can move it, resize it from any corner, maximise it, or minimise it to a strip.

The dock

The window can be docked to a panel down the right-hand side, half the viewport wide by default and draggable from there. The page reflows around it rather than being covered.

Dock the panel to work through a diagram shape by shape while the drawing stays put.

A folium is a documentation site. Left rail of pages, content in the middle, automatic table of contents on the right. Use one when the thing you are writing runs longer than a single blueprint: a handbook, a reference, a set of runbooks.

You are reading one now.

Folium or blueprint?

A folium page can embed a blueprint, which keeps the diagram a first-class object instead of a screenshot.

Ownership

Foliums are owned by an organisation and require a Teams licence. They are served from the organisation's subdomain, or a custom domain if one is configured.

A folium is a tree of pages. Depth and page count are capped generously; the practical limit is what a reader can navigate.

Page kinds

Ordering and icons

Drag rows in the manage view to reorder. Each page takes an optional icon from a curated Lucide set; a page without one gets a disc.

A page can be hidden from the nav and stay reachable by URL. Use that for a page that is only ever linked from elsewhere.

Slugs and redirects

A page's slug is its URL segment, and the full path is built from its ancestors. Changing a slug or moving a page records a redirect automatically, so old links keep working with a 308.

Drafts

A page can be published or draft. Draft pages are invisible to readers and are excluded from search and from embeds. The link-draft diagnostic flags any published page that links to one.

Sizing the tree

Ten collapsed top-level groups is comfortable. Beyond that, readers stop scanning the rail and rely on search instead.

Folium pages are markdown, edited either in the browser or in your own editor.

Frontmatter

Components

The component library is available in full: callouts, steps, tabs, accordions, tiles, fields, trees and the rest. It is the same pipeline that renders blueprint rich text.

Includes

A fragment can be written once and included in several pages, so a warning or a set of prerequisites has one source. Editing the fragment updates every page that includes it.

Variables

Settings can define variables that pages interpolate: a product version, a base URL, a support address. Changing the value updates every page at once.

Audience splitting

[!VISIBILITY agents] content is stripped before the page reaches a human, and [!VISIBILITY humans] content is stripped from the markdown an agent fetches. Use it for machine-readable hints that would clutter the page.

A folium's configuration is in one place, reachable from Manage → Settings. Everything below is optional and fails closed: a feature is off until you turn it on.

Where each control is

Two surfaces sit above the settings keys. Customize is the panel that opens beside the page you are reading. Manage is a full page.

Layout

Chrome

Content behaviour

Features

Versions and rollback

A version is a manual snapshot of the site, taken from the Versions tab of the Customize panel. Type a label, press Publish version, and readers gain a selector in the top bar. Latest there is the live working set you edit.

The snapshot captures your published, non-archived pages and their strata. Nothing else. Every key on this page, along with the theme, custom domain, redirects and uploaded assets, is served live, so editing any of them changes what a pinned version looks like today. A version is also served in the folium's default language whatever the reader picks, and editing is switched off while a version is selected.

The first version you publish becomes the default at once, so readers move off Latest the moment it exists. Clear default (readers see Latest) puts them back.

Deleting a version takes effect on the click, with no confirmation and no undo. The snapshot goes; the pages it was taken from stay.

A folium with no published page refuses with Nothing to publish yet, and one whose pages and strata serialise past roughly 4 MB refuses with This folium is too large to snapshot. Where requirePublishApproval is on and you are not a folium admin, Publish version files a change request for an admin to review rather than writing the snapshot.

Analytics and consent

Third-party measurement ids you configure here are consent-gated, and are never mounted on an embed surface. An embed writes nothing to the reader's device.

A folium takes its look from the owning organisation, then lets you override the theme, navbar, footer and banner.

Theme

Pick a preset or set colours directly. The reader's light or dark preference is respected either way, so choose colours that work in both.

Navbar

Link columns across the top, plus one primary call to action. Keep it to one; a navbar with four equally weighted buttons has no call to action.

Footer

Link columns and social links. Social keys come from a fixed list rather than an open map, so the footer can only render icons it has.

Banner

A site-wide strip above the reader chrome, in one of four tones. Use it for something time-bound, such as a migration window or a deprecation date, and take it down when that window closes.

Custom domain

An organisation can serve its folia from its own domain.

Every folium has its own search, scoped to that folium. It covers page titles and page bodies, so a reader can find a paragraph rather than only a page name, and the result shows the matching excerpt.

What each reader sees

Search mirrors exactly what the person searching can open:

It also follows the reader's context: the pinned version when one is selected, and the translations for the locale they are viewing.

Settings

Manage → Documentation settings → Search.

Page descriptions

Write a description on every page. The result snippet falls back to it, and link previews show it. Diagnostics has a missing-description rule.

Search analytics

Analytics records what readers searched for, which terms returned nothing, and which results were clicked. A term with searches and a 0% click-through is a ranking or naming problem: the page exists, and its title does not read as the answer.

Hidden pages are still readable

The assistant answers questions using the folium's own pages as its source. It is off until you enable it.

What it can see

Only the folium's published content, plus the prompt material you supply in settings. It has no access to anything outside the folium.

Prompt material

Settings hold instructions for the assistant: tone, what to do when it does not know, which pages to prefer. Write them as guidance to a person rather than as configuration.

The widget

The assistant can be embedded on another site as a widget, so your product's own UI can answer documentation questions in place.

What it will not do

The assistant does not edit pages. Asked for a change, it files a change request for a person to review.

Import an OpenAPI or AsyncAPI document and the folium generates reference pages in the same chrome as the rest of your documentation: endpoints, parameters, request and response shapes.

Manage → API specs.

Importing

Each import is filed under a key you choose. The key controls what happens when you import again:

A versioned API is two keys. A moving API is one key re-imported.

Give it a source URL or paste the document. A pasted body takes precedence over the URL.

The playground

Each endpoint can have a live request panel: fill in parameters, send, and see the response. Requests are proxied, so the reader's browser does not make cross-origin calls to your API directly.

In exports

The reader menu has an Inline the resolved API schema in .md exports option. With it on, an agent that pulls the markdown gets the schema inline rather than a link to it.

Writing by hand

You do not have to import anything. The [!FIELDS] component produces the same parameter and response layout from markdown, for a small API or for a single endpoint described in prose rather than generated from a schema that documents forty.

A folium can publish a changelog: dated entries, each anchored so it can be linked to directly.

Writing an entry

> [!UPDATE v2.1.0|2026-09-05]
>
> The playground now remembers the last request per endpoint.

Entries are ordinary page content and can hold anything a page can, including diagrams.

Feeds

The changelog is published as a feed at changelog.xml, alongside the folium's rss.xml. Readers can subscribe in a feed reader without an account.

Email subscriptions

Readers can also subscribe by email and be notified when you publish a new entry. Off by default.

Reader access is set on the folium's Manage page, in the Visibility section at the top. Only a folium admin or owner can change it.

The three levels

Private is the default for a new folium, and the Teams licence gate applies.

Changing it

Open the folium, choose Manage, then pick a level under Visibility. The change saves on click; there is no separate save step.

Unlisted with a password

An unlisted folium can carry a shared password. Readers enter it once and a cookie remembers them. That covers a client handover, but records no reader identity, so it cannot tell you who read what.

What public changes

Private and unlisted foliums are served noindex, nofollow. Public is the only level a search engine will index.

A public folium with no password is also served an MCP endpoint, listed under MCP on the Manage page, so agents can search and read it. Setting a password or moving back to unlisted withdraws that endpoint.

Reader identity

Readers authenticate against your identity provider and get a session tied to who they are. That session supports per-reader access and per-reader records of who read what. It layers on top of the level above rather than replacing it.

A folium can be connected to a markdown repository so the same content exists in both places. GitHub and GitLab, cloud only.

Configuring it

The token is encrypted before storage and is never shown again, sent to the browser, or written to a log. It is not part of the settings object, so it cannot reach a reader.

Pull

Markdown files in the repository become pages. Documentation sits beside the code, is reviewed the same way, and the folium is the published surface.

Push

Pages are written back as a new branch for you to review in your repository. Push never commits directly to your default branch.

The alternative

To author locally without connecting a repository, the CLI pulls and pushes a directory of markdown over the API. It uses no Git and stores no token on our side. It also validates against the server's own rules offline before it uploads anything, which repo sync does not.

An automation runs the documentation agent over the folium and files a change request with what it proposes.

The agent is allowed to be wrong, because a wrong proposal costs a rejection rather than a corrupted page.

Predefined automations

Start from one of these rather than describing a job from scratch:

New automation takes your own instruction instead.

Reviewing a run

A run produces a change request. Open it, read what it proposes, and accept, edit or reject page by page. A rejected proposal leaves the page untouched.

When to use diagnostics instead

Diagnostics is a rule engine, not a model. It is exact, costs nothing, and finishes in seconds. Use diagnostics for anything mechanical: broken links, dangling redirects, missing descriptions, unknown icons. Reserve automations for the judgement calls a rule cannot make.

Diagnostics with external link checking needs no agent. Internal links break when someone deletes a page; external links break when the site at the other end changes.

Markdown

Every page can be fetched as its source markdown, mainly for agents reading your docs programmatically. Settings control how those exports are composed.

Content marked [!VISIBILITY humans] is stripped from the agent-facing markdown, and [!VISIBILITY agents] content is stripped from the page a person reads.

Print

A folium can produce a print-optimised document covering the whole tree or a subtree, with sensible page breaks, resolved links and diagrams rendered inline.

The CLI

blueprintr-docs pull writes the whole folium to disk as markdown files with frontmatter, and push uploads them back.

Diagnostics check a folium against a fixed rule set. Run them from the manage view, from an automation, or offline with the CLI.

The rules

External links

External checking is off by default and only runs server-side. Probing an author-supplied URL needs the platform's request guard, which refuses private, link-local and metadata addresses. The CLI collects external links and lists them but never fetches them.

Links resolve like a browser

An internal link resolves against the page's URL the way a browser would. A bare sibling written on the page a/b means a/sibling, not a/b/sibling. Writing links as absolute in-app paths avoids the problem.

Manage → Documentation analytics, over the last 7, 30 or 90 days. Every panel exports as CSV: Traffic, Pages, Referrers, Searches, Assistant, Feedback.

Traffic

Top pages breaks the human/agent split down per page in two columns, and agent traffic by kind separates ordinary crawlers from AI/LLM agents.

A page with heavy agent traffic and no human traffic is being read by machines only. That is expected for reference material, and a signal if you wrote it for people.

Engagement

Average read depth across sessions: how far down the page readers get. Top outbound clicks lists the destinations readers leave for, which indicates what your documentation does not answer.

Search

Searches, distinct terms, click-through rate, and zero-result searches. Top terms shows each term with its CTR and the result readers picked.

Searched, found nothing lists each term and when it was last searched.

A term with searches and a 0% click-through means the page exists and its title or description does not read as the answer.

Assistant

Conversations and messages, broken down by the surface they came from, plus recent conversations. What readers ask the assistant is the same demand signal as a failed search, in full sentences.

Page feedback

Helpful, not helpful, total responses and helpful rate, with the lowest-rated pages for the window. Rating is independent of traffic, so a popular page can sit near the bottom of that list.

Your own measurement

Manage → Analytics integrations accepts GA4, PostHog (with a custom host), Mixpanel and Segment ids, plus first-party click-heatmap sampling. Measurement ids are public.

These mount on public and unlisted pages only. They are consent-gated, and are never mounted on an embed. An embed writes nothing to the reader's device.

blueprintr-docs is a command-line tool for writing documentation in a text editor instead of a browser.

node /path/to/blueprintr/cli/bin/blueprintr-docs.mjs --help

Its only dependencies are Node builtins, so there is no install step and nothing to audit beyond the tool itself.

Commands

Validate

blueprintr-docs validate ./docs --strict

validate makes no network calls and needs no credentials. It loads the server's own diagnostics module rather than reimplementing the rules, so a local pass and a server pass cannot disagree.

Exit codes are 0 clean, 1 findings, 2 bad command line, 3 credentials, 4 network, 5 filesystem.

Layout on disk

folium.json is optional and holds the slug, redirects, disabled rules and the known icon list. A directory with no index.md still becomes a nav section.

Pull and push

export BLUEPRINTR_TOKEN=bpk_user_…
blueprintr-docs pull handbook ./docs

Frontmatter holds the page id, and that id is how push matches a file to a page. Editing or removing it makes push create a new page instead of updating the existing one.

push never deletes a page. A page on the server but not on disk is reported and left alone, so running the command in the wrong directory cannot cost you a page. It never publishes a draft either: publishing stays an in-app action, and push can retract a published page to draft but not the reverse. Link and external pages are left untouched, because they point at something rather than holding content.

The token

BLUEPRINTR_TOKEN is a personal API key from Dashboard → Settings → Developer. It is read from the environment and never from a flag, because argv appears in ps and in shell history. Every line the tool prints is passed through a redactor.

Organisation keys are rejected: they are read-only and scoped to public documents.

Links resolve like a browser

A page at guides/index.md has the URL /guides, so a relative ./aws/setup from that file resolves to /aws/setup, not /guides/aws/setup. Writing links as absolute in-app paths (/foliums/<slug>/guides/aws/setup) avoids the problem.

Manage → Migrate from another platform takes an export from an existing documentation tool and turns it into folium pages.

Leave the source on Detect automatically unless it guesses wrong.

What to upload

The export archive the other tool produces, as a .zip of up to 32 MB. A repository URL or a live site address is not accepted.

Nothing is written until you say so

Upload and preview parses the archive and shows you the page tree it intends to create. You approve it, and only then does anything land.

After the import

What does not come across

Anything that was a feature of the old platform rather than content: its theming, its custom components, its redirects. List your existing redirects before you migrate. A folium records a redirect when it moves a page, and cannot inherit one from a tool it never ran.

The other routes in

How published content reaches readers: who can see it, how it appears elsewhere, and where it is served from.

Visibility sets who may read a blueprint once it is published.

Unlisted links

An unlisted URL is unguessable, not protected. It survives being forwarded, pasted into a ticket, or sitting in someone's browser history after they leave.

Status comes first

An unpublished draft is invisible regardless of its visibility setting. Visibility only takes effect once you publish.

Organisation policy can override you

An organisation can apply a classification that caps how public its content may be. Where a classification is set, you cannot publish above the ceiling it defines, and the Publish step says so. See policies.

Each surface gates independently

A blueprint's visibility does not automatically govern every route that can reach its content. Files, embeds, discussion and analytics each apply their own check. A mistake in one place cannot open all of them.

A published blueprint can be embedded elsewhere as a live, interactive frame. Readers pan the diagram and open strata without leaving the host page.

Getting the code

Use Share → Embed on a published blueprint. You get an <iframe> snippet.

The embed URL follows the blueprint's own address:

https://blueprintr.io/embed/<handle>/<slug>

Sizing

The frame reports its own height to the host page, so it grows to fit its content rather than scrolling inside a fixed box. Height and width can also be pinned explicitly.

Pinning a version

An embed can track the latest published version or be pinned to a specific one. Pin it when the embed illustrates a point in time, such as a design as it stood at a decision. Leave it tracking when it should stay current.

What an embed does not do

Strata open as floating windows inside the frame rather than docking, because there is no page to reflow.

Visibility

Only public and unlisted blueprints can be embedded anonymously. A private blueprint's embed requires the reader to be signed in and permitted, and organisations can restrict embedding to an allow-list of hosts. See enterprise embeds.

Link previews

Paste a public blueprint's URL into a chat tool, a wiki or a social post and it unfurls: title, description and a preview image of the diagram.

The preview image is generated from the blueprint itself, so it shows the actual drawing rather than a generic card.

oEmbed

Blueprintr is an oEmbed provider. Tools that support oEmbed can turn a pasted link into a live, interactive embed rather than a static preview. It is the same frame described in embedding, with no iframe snippet to copy.

Support varies by tool. Where a tool does not recognise the provider, the link falls back to an ordinary preview.

Private content

Only public and unlisted content unfurls. A private blueprint's link shows nothing beyond the URL. An unfurl in a chat channel would otherwise leak the title to everyone in it.

An organisation can serve its published content from its own address.

Subdomain

Claim a label and the organisation's Atrium and folia are served from <label>.blueprintr.io. This needs no DNS work.

The label is claimed once and becomes part of every URL underneath it.

Custom domain

Point your own domain at Blueprintr instead. Add the domain in the organisation's domains console and create the DNS records it shows you. Verification is automatic once the records resolve, and certificates are issued for you.

What moves

Reader authentication

If you use reader authentication, the sign-in route must be reachable on the domain your folia are served from. That is edge configuration rather than a setting; confirm it with whoever operates the deployment before relying on it.

A podium turns a Vellum diagram into a presentation. Each slide is a framed region of the canvas; presenting pans and zooms between them.

The diagram stays the source. There is no export step, so the deck cannot drift from the drawing.

Slides and chapters

A slide is a view of the diagram rather than a copy. Editing the diagram changes what the slide shows.

A chapter is a diagram tab. Slides belong to a chapter, and the audience walks one flat sequence across every chapter in order: chapter one's slides, then chapter two's, and so on. Reordering within a chapter reorders the talk; reordering the tabs reorders the chapters.

The transition follows that structure:

Put a change of subject in a new chapter, and keep one argument's slides in one tab.

Presenting

Present mode fills the screen. The keys:

The pill shows the current slide's name, falling back to "Slide n" when you have not named it. The chapter name is in the pill's tooltip rather than on the pill itself.

The laser pointer (L in the editor) works here too.

Strata as speaker material

A slide can show the strata attached to shapes in view, as cards beside the diagram.

Sharing

A podium is part of its blueprint and inherits its visibility. Anyone who can read the blueprint can step through the podium.

What it is

A browser extension that records what you do in a tab and turns each captured frame into a slide in a Blueprintr Podium.

It is a recorder, not a presenter. Walking through a flow once produces the deck; you present it afterwards from the podium itself.

• One-click frame capture
• Frames push straight into a Podium draft

What already exists

The app-side contract is built and live. Frames upload directly to storage with presigned URLs in an init → per-frame upload → finalize handshake. Image bytes never pass through the API server.

Finalize is idempotent: retrying the same capture does not create a duplicate tab.

Access

The extension will show only podiums you can already reach, and can only write to a blueprint you can already edit.

Presenting today

Until the recorder ships, build a podium the ordinary way, from a diagram's slides in the editor, and present it from the browser. See Podium.

An Atrium is the front door to an organisation's content. One page listing what the organisation has published, with search across all of it.

What is on it

Configurable blocks: featured content, recently updated items, the documentation sites the organisation runs, teams, and people. An organisation can publish without an Atrium.

Who can see it

The Atrium respects each item's own visibility. A visitor sees the public subset; a member sees everything they have access to.

Where it is served

At the organisation's subdomain, or its custom domain if one is configured. See subdomains and custom domains.

Search

Atrium search covers the titles and bodies of blueprints and folium pages, scoped to the organisation.

Keeping things where you can find them.

A portfolio is a folder. It holds blueprints, standalone diagrams, links and notes, and it can hold other portfolios.

Main

Every workspace has a Main portfolio, created automatically. Anything you make without choosing a home lands there. It cannot be deleted.

One home each

An item is in exactly one portfolio at a time. Filing is a move, not a copy.

Ownership

A portfolio is owned by you, a team, or an organisation, the same three owners as everything else. A portfolio's owner and its contents' owner are independent: filing an organisation blueprint into a personal portfolio does not make it yours.

Nesting

Subfolders go as deep as you want. Two or three levels is usually enough.

Links and notes

A portfolio can also hold plain links and short notes, so a folder can keep the context around a set of blueprints: the ticket, the decision record, the "read this first".

Search

Cmd K anywhere on the platform opens search. It covers titles and bodies of the blueprints and folium pages you have access to, so you can search for a phrase you remember rather than a title you do not.

You never see a result you could not open.

Official Blueprintr documentation is included in results, so a question about the product itself is answered from the same box.

Bookmarks

Bookmark anything you can read. Bookmarks are personal, sit under Dashboard → Bookmarks, and survive the item moving between portfolios.

They are not a substitute for filing.

The import wizard is at Dashboard → Import. Connect a source system, or upload files.

Connecting a source

Confluence, Notion and SharePoint connect through a grant you authorise. You then choose which spaces, databases or sites to bring across, and Blueprintr converts pages into blueprints or folium pages.

Each shows a Requires setup badge until someone with admin rights has configured the connection for the workspace. Files needs no setup.

Uploading files

Drop files on the target or browse for them. Up to 200 files per import.

Diagrams

Imported diagrams are converted where the source format allows it. Anything that cannot be converted comes across as an image, so the content is never lost. Redraw it in Vellum afterwards.

Watching a job

An import runs as a job with its own progress page. Large imports continue in the background; you do not need to keep the tab open.

Deleted items go to Dashboard → Trash rather than disappearing. Blueprints, portfolios and Vellum saves all land there.

The thirty-day window

Trash lists everything deleted in the last 30 days that you can restore: your own rows, plus team and organisation rows where you hold the role that would let you restore them.

Items older than thirty days are listed separately, below, as a heads-up.

Restoring

Restoring puts an item back where it was. If its portfolio has since been deleted, it returns to Main.

What a delete takes with it

A folder delete must never be a content delete, which is why a portfolio is the exception.

Permanent removal

Permanently delete on a row, or emptying trash, is exactly that. It is not covered by version history and there is no second bucket behind it.

An organisation is the account: billing, domains, policy, and the people. A team is a group inside it with its own members and its own content.

Bought a Teams licence? Start with Setting up an organisation. The licence, the people and the teams all attach to one.

When to add a team

Add one when a group needs its own content boundary: a different set of people editing a different set of blueprints. Do not add one per project; that is what portfolios are for, and they cost nothing to create.

Built-in roles

Every membership has one of three built-in roles, and they are strictly ordered: owner > admin > member.

Owners and admins hold every permission implicitly. Members hold what their custom roles grant.

A Teams licence belongs to an organisation, not to the person who pays for it, so the organisation comes first: create it, license it, invite people, add a team.

An organisation whose licence is not active is read-only. It refuses invitations, new teams, subdomain changes, settings edits and publishing, and each refusal says why. It still lets you buy the licence.

After the licence

Inviting

Organisation → Settings → Manage members → Invite by email. An invitation is sent by email with the role you chose. It can be revoked before it is accepted.

Inviting requires the member.invite permission. Owners and admins have it implicitly.

Seats

Members consume seats against your plan, and a pending invitation reserves a seat until it is accepted, revoked or expires. The seat count and what is left are on the organisation's Plan & seats page. Seats are changed from Licensing & Billing, not from the members page.

An organisation with no active licence cannot invite anyone. See Setting up an organisation.

Removing someone

Removing a member (member.remove) revokes their access immediately, including anything derived from their membership, such as access to team content and any custom roles they held.

Joining through SSO

Where SSO is configured, people sign in through your identity provider instead of accepting an invitation. With SCIM, membership is provisioned and deprovisioned automatically from your directory.

Members keep their built-in role (owner, admin or member) and can hold custom roles on top. A custom role is a named bundle of permissions.

Owners and admins short-circuit the check: they hold everything. Custom roles are how you give a member a specific capability without making them an admin.

The catalogue

People

Content

Structure

Governance

Integrations and platform

Designing roles

Keep the count small. Every role is something a future admin has to understand before they can safely change anything.

Policies are rules the organisation sets that individual members cannot override. They are enforced at the point of publishing.

Editing them needs policy.update.

Classification

A classification caps how public a piece of content may be. Where one applies, the Publish step will not offer a visibility above the ceiling, and says why.

Publish approval

Publishing can require a second person. Where it is on, publishing becomes a submission and the content waits in Reviews for someone with blueprint.review to approve.

The same setting exists per folium, so documentation can require approval while blueprints do not, or the reverse.

Where policy wins

A workflow is a named, enforceable sequence of steps that content moves through, such as "this needs sign-off from two people, one of whom is in security".

Steps

Each step names who can act on it and what acting means: approve, reject, or pass to the next step. Steps run in order, and content cannot skip one.

Where a run starts

A run is created when the event a workflow is bound to happens, usually a publish attempt. The content stays in its pre-publish state until the run completes.

Cancelling

A run can be cancelled, which returns the content to the author. Cancellation is itself an authorised action.

Workflows and policies

Publish approval is the one-step case. Use a workflow when one approval is not enough: when the approver depends on the content, or when several groups must sign in order.

Dashboard → Reviews is the queue. It holds content submitted for approval because a policy or a workflow requires it.

Acting on it needs blueprint.review.

What an approver sees

The content as readers would see it, plus what changed since the last published version. On a first publish there is no previous version, so all of it is the change.

Decisions

Multi-step workflows

A workflow is an ordered list of steps, and a run sits on exactly one of them at a time. Approving advances it; the run is only finished when the last step approves.

Each step names its approvers two ways, and either is enough:

Only the current step's approvers can act. Being an approver on step three does not let you approve step one.

Change requests are different

A change request is a proposal from someone without edit rights. A review is a gate on someone who has them. An author can withdraw their own change request, where only an approver can resolve a review.

Documentation has its own version of this: a folium with requirePublishApproval files a change request instead of publishing when a non-admin publishes a version, and the REST API answers 202 Accepted rather than an error.

The audit log records consequential actions across the organisation. Reading it needs audit.read.

What is recorded

Roughly 210 distinct actions, named <target>.<what> or <target>.<noun>.<verb>: blueprint.acl.revoke, blueprint.visibility.update, apikey.revoke, enterprise.scim.deprovision.

They hang off twenty-one target types:

blueprint · user · team · org · invite · setting · portfolio · portfolio_folder · portfolio_item · diagram · vellum_save · comment · license · template · folium · integration · cloud_connection · continuum_integration · enterprise_tenant · lead · lead_company

Each entry records who acted, what they acted on, when, a structured diff of what changed, and enough request context to tell one session from another.

What it does not keep

Append-only, and enforced twice

No codepath in the application updates or deletes an audit row.

Enterprise actions are catalogued

Action strings are free-typed except in the enterprise.* namespace. Thirty-five constants cover tenancy, contracts, SSO, SCIM, IP allow-listing, classification, white-label domains, integrations and stack provisioning, so an enterprise event cannot be recorded under a name that differs from the one you are searching for.

Teams

Teams have their own audit view scoped to their own content, so a team lead can review their area without being granted organisation-wide audit.read.

Enterprise features control who can sign in to an organisation and what happens to its content.

Licensing

Enterprise features are enabled per organisation as part of a licence rather than switched on from a settings page. Several also need provisioning on the platform side.

Your organisation's current entitlement is on its licence page, visible to anyone with license.read.

SSO lets members sign in through your identity provider instead of holding a Blueprintr password. Blueprintr supports Okta, Entra ID, Google Workspace and any SAML 2.0 or OIDC provider.

Configuring it needs sso.manage.

What you will exchange

Setting up a connection is an exchange of metadata:

Sign-in behaviour

Once connected, members sign in through your IdP. Whether that becomes the only way in is a separate decision. Enforce it once you have confirmed a working login and an owner who can still get in if the IdP is unavailable.

Provisioning

SSO decides who may sign in. SCIM decides who is a member and removes access when someone leaves your directory.

SCIM keeps Blueprintr membership in step with your identity provider, including deactivating people who leave. Configuring it needs scim.manage.

SCIM and SSO

SSO controls authentication. SCIM controls membership. Without it, a person removed from your directory keeps their Blueprintr membership until an admin removes it by hand, and the seat stays billed.

How it flows

There is no inbound public SCIM endpoint on Blueprintr. Your IdP pushes SCIM 2.0 to the SSO service, which normalises and stores it; Blueprintr then pulls that directory state and projects it onto memberships and roles.

• The SCIM base URL and bearer token you configure in your IdP belong to the SSO service rather than to a Blueprintr API.
• Changes land when a reconcile pass runs, not the instant your IdP sends them. Real-time push is a future enhancement.

Each reconcile applies the cumulative effect of every event since the last one and diffs directory state against local state, so it doubles as drift detection. The delta is audited.

What is enforced

What is not enforced

Group-to-role mapping is additive and one-way:

One-way mapping stops SCIM undoing a role an admin granted by hand, and stops a mis-scoped IdP group locking an organisation out of its own tenancy.

Drift in the unenforced direction is reported in the run summary rather than acted on. Read those summaries: a role someone should no longer hold shows up there.

Setting it up

Configure the directory in Organisation settings → Enterprise → SCIM. The page is unavailable unless enterprise SSO is enabled for the deployment and the SSO service is reachable. A greyed-out page is a platform prerequisite rather than a permission problem.

The token is shown once. Store it in your IdP immediately. Regenerating invalidates the old one.

Auditing

Every SCIM operation writes an audit entry under its own action: configure, provision, deprovision, reconcile, rotate, toggle and delete. A membership that changed because of your directory is distinguishable from one an admin changed by hand.

Network access rules limit which source addresses may reach your organisation's content. Configuring them needs network.manage.

How rules apply

Rules are evaluated per request against the caller's address. A request from outside the permitted set is refused before it reaches any content.

Coverage

Network rules govern access to your organisation's content. They do not apply to published public content: a blueprint you have made public stays reachable regardless of the rule.

To restrict who reads documentation, use visibility and reader authentication rather than network rules.

Client addresses

The address a rule is evaluated against is determined at the platform edge, not taken from a request header.

By default a public blueprint can be embedded anywhere. An organisation can narrow that to an allow-list of hosts.

Managing it needs integration.manage.

Allow-listing

Add the hosts permitted to frame your content. A request to embed from anywhere else is refused, and the frame stays empty rather than rendering.

Use it for public content, such as a reference architecture or a standard, that you want read in context rather than embedded in somebody else's product.

Authenticated embeds

Private content can be embedded on a permitted host with the reader authenticating first. The reader signs in, and the embed then resolves against what that person may see.

A connector links your organisation to an external content system. Once connected, a blueprint tab can render content from it in place, rather than holding a copy that drifts.

Managing connectors needs integration.manage.

Source-embed tabs

A source embed tab names a page in the connected system. Blueprintr fetches it when the blueprint is read, using the viewer's own permission in the source system.

Because it is a per-viewer privileged fetch, source-embed tabs do not render on anonymous surfaces: marketing pages, public embeds, or a frozen version snapshot. Those show an inert reference card instead.

Import versus connect

Importing copies content in once and it becomes yours. A connector leaves the content where it is and renders it live. Import when you are migrating; connect when the other system stays the source of truth.

Continuum connects a diagram to the systems it describes, so the drawing can be regenerated and the detail on it comes from the source.

Two products, two licences

Both are set up in the same place, Settings → Continuum on an organisation or a team. In the blueprint editor the menu that offers both is headed "Continuum Link", which is a leftover from when the two shared a name. The row labelled Continuum is the Cloud one.

The Cloud pipeline

Continuum Cloud reads a live AWS account or Azure subscription and draws it as a Vellum diagram inside a blueprint. Every discovered resource also gets a stratum holding its configuration, so the drawing and the detail behind it both come from the source.

It needs a Teams plan or above, and cloud_connections.manage on the organisation or team that owns the connection. Below Teams, creating a connection refuses with "Continuum is a Teams-plan feature."

What it produces

One Continuum tab in a blueprint, backed by a private Vellum document named after the tab. Alongside it:

Resources that describe relationships rather than occupy space, such as route tables, security groups, network ACLs, IAM and KMS, get a stratum with no shape. They are filed under a (Context) folder in the Files sidebar and cross-linked from the resources they affect.

A resource collapsed into a group shape, such as Auto Scaling members or a Lambda name family, also gets a stratum with no shape of its own. Those sit alongside the drawn resources rather than under (Context).

Building one

What is discovered

Continuum discovers 77 AWS resource types and 75 Azure resource types. Of those, 53 AWS types and 52 Azure types are drawn as shapes by default. The rest are read for their relationships, for the containers they define, or for stratum context.

Views on the same canvas

The canvas carries a View switcher. Base topology is the default; the others recolour the same shapes to answer one question each: Routing, Security groups, Cost (est.), IP addresses, Public exposure, Availability zone and Tag coverage. Views authored on the diagram appear in the same list.

Keeping it current

Syncing is manual on every plan. Open the tab's settings cog and choose Sync now to re-discover every scope, or Re-sync one scope from Settings…. A sync preserves the canvas you saved and reports its result as "Synced, +3 added, 1 changed, 0 missing."

Scheduled syncing is not available. Choosing a cadence under Auto-sync returns "Scheduled polling is not available yet - Continuum runs one-time scans." That is not a plan gate, and no upgrade lifts it.

Keeping diagrams true covers what a refresh preserves, what the shape outlines mean, and how newly discovered resources are promoted onto the diagram.

Binding one shape instead

A shape you drew yourself can be bound to a single live resource without generating a whole diagram. Add a stratum to it, open + Add tab and choose Continuum. AWS and Azure connections can both be bound. A Terraform-state connection cannot, because a state snapshot has no live resource to re-read.

Continuum Cloud is not Continuum Link

Continuum Cloud draws. Continuum Link brings operational data from monitoring, on-call and ITSM platforms onto a stratum and never touches a canvas. They are separate products on separate licences, and the editor menu that offers both is headed "Continuum Link" for historical reasons.

A cloud connection is the read-only credential Continuum Cloud uses to discover your estate. Create one from Settings → Continuum on an organisation or a team.

You need cloud_connections.manage on that organisation or team, and a Teams plan or above. Below Teams the action refuses with "Continuum is a Teams-plan feature." Without any integrations permission the page returns a 404 rather than telling you the organisation exists.

Teams allows three connections per owner. Reaching the cap refuses with "Connection cap reached (3 per org)", or "(3 per team)", naming whichever owns it. Blueprintr first reclaims your own drafts that have sat untouched for a day with no credential of any kind and nothing referencing them. Drafts created by someone else, and your own from the last 24 hours, are left alone, so the cap can still refuse. Enterprise has no cap.

Read-only, always

AWS

The first step asks for your own 12-digit AWS account number, not for anything to copy back. Blueprintr then offers a prepared CloudFormation template through Launch in AWS, creates a read-only role, and watches for it to appear. If the CloudFormation form asks for an External ID, paste the one shown beside the launch button; the current template fills it in already. The external ID is what stops another tenant assuming your role.

If the watch times out, a collapsed panel lets you paste the role ARN yourself.

Choose the scope of the grant first

Connection scope offers two modes. It stays changeable while the connection is a draft, by going Back in the wizard. Once a role has been recorded it is fixed: "This connection already has a role, so its scope can't be changed. Create a new connection instead."

Organization mode is run from the management or delegated-admin account and needs trusted access between AWS Organizations and CloudFormation StackSets, which is enabled once per organisation. A single-account role cannot serve an organisation-mode connection, and the mismatch fails at inventory time rather than at creation.

Azure

Register an Entra application, create a client secret on it, and grant it the built-in Reader role on the subscriptions you want visible. Paste back the Directory (tenant) ID, the Application (client) ID and the Client secret value, which is the value rather than the secret id, and which Azure shows once. Where policy forbids built-in Reader, the wizard offers a narrower custom role definition to create instead.

An Azure connection authenticates with a client secret. Workload identity federation is not available, so the wizard has no Federation option.

You create the secret in Azure. The copy-and-run script the wizard offers creates it with a two-year life; the portal click-path leaves Azure's own default, so check it. Blueprintr encrypts it at rest and never returns it to the browser. Replace it later from the connection's detail page rather than by rebuilding the connection.

One Azure connection covers a set of subscriptions. A connection whose app registration has no Reader grant fails verification outright: "The connection authenticated but no subscriptions are visible to it. Assign the Reader role at subscription scope." Grant Reader, then verify again.

Google Cloud

Continuum Cloud does not discover Google Cloud, and the wizard offers AWS and Azure only. Google Cloud Monitoring is available as a Continuum Link connector, which attaches alerting policies to shapes you draw yourself.

Terraform state

Terraform is not an alternative to granting access. Add a cloud connection first, then set a backend on that connection's detail page under Terraform backend. Continuum reconciles what you declared against what discovery found, and outlines a resource whose live configuration has diverged from state in amber.

For S3 remote state, give the bucket, object key and bucket region, and add s3:GetObject on the state object to the Continuum role policy. The template role cannot read bucket contents on its own.

For Terraform Cloud, give the workspace id and a workspace-scoped token with state:read. Saving without one is refused: "A workspace token is required when switching to Terraform Cloud."

A Terraform-source connection cannot back a single bound shape, because a state snapshot has no live resource to re-read.

Verifying

Verify re-proves the credential: an assume-role and identity check for AWS, a token plus subscription and resource-group read for Azure, and a fetch and parse for Terraform state. Discovery only runs on a connection that has verified, so verify after any credential change.

Regions and deletion

Regions are fixed when you create the connection: one region in single-account mode, a set of regions in AWS Organization mode. There is no region control on the connection afterwards, so covering a new region means a new connection.

Which of those regions a particular diagram uses is a separate choice, made per diagram under scopes.

Deleting a connection is refused while an integration or scope still references it: "Connection is in use by N integration(s) and M scope(s). Remove those first." A shape bound to the connection, or a Continuum Link connector borrowing its role, also blocks the delete, so unbind those too.

A scope is what one Continuum diagram covers. On AWS it is one account paired with one region. On Azure it is one subscription paired with one location.

A diagram can carry several, but they must all come from the same provider. Adding an Azure scope to an AWS tab is refused: "This Continuum tab was created from a different cloud provider. Add the scope to its own Continuum tab instead."

Choosing scopes

Pick accounts or subscriptions, then regions. Every combination becomes its own scope, so three accounts and two regions is six scopes. The picker shows the running total.

These optional narrowings apply on top:

A resource is imported when every tag listed matches. The filter applies to all selected scopes.

One commit fans out to at most 12 scopes on AWS and 4 on Azure, and the picker says so when you go over.

On Teams the plan cap of three scopes per diagram bites first, and the picker does not know your plan. A selection of four or more still shows as valid and the server refuses it after you press create. Narrow the selection, or add the rest as extra scopes afterwards.

Adding, re-syncing and removing scopes

Open the Continuum tab's settings cog and choose Settings…. Each scope has Re-sync, and + Add another scope adds more.

Every control here needs edit access on the blueprint plus cloud_connections.manage on each scope's connection. Without the permission the buttons do not appear.

Remove is disabled on the last remaining scope: "Cannot remove the last scope. Delete the Continuum tab instead."

Syncing is manual

Sync now from the cog re-discovers every scope and reports the result, for example "Synced, +3 added, 1 changed, 0 missing."

Reading a sync

Each scope's discovery is recorded as its own Poll run, reachable from the history list in Settings…, so one Sync now across three scopes produces three runs. Removing a scope writes one too.

A run reports what it found, what changed since the last one, and an Adapter errors section listing every read that failed.

Check that section before concluding something was decommissioned. A permission error produces a smaller diagram with an explanation, not a silent gap. Once the permission is fixed, choose Sync now again.

The ten most recent runs are listed. There is no view that compares two runs side by side.

Limits

Continuum Cloud caps, enforced:

Continuum Link caps, enforced:

Continuum Link needs Enterprise, so its Team column applies only where an Enterprise entitlement has lapsed.

Team settings → Plan & limits also shows Resources per integration as 200 on Teams and unlimited on Enterprise. Nothing enforces that figure, and a sync is not truncated at 200 resources. The same card shows Scheduled polling as "Scan only" on both tiers.

Once a scope has been discovered, Continuum puts the results on a canvas and mints a stratum for every resource it found.

Shapes and strata

Resources the layout draws become shapes, nested inside the boundaries that exist in the source: accounts, regions, VPCs and subnets, resource groups.

Resources that describe relationships rather than occupy space get a stratum with no shape. Route tables, security groups, network ACLs, IAM and KMS are filed under a (Context) folder in the Files sidebar and cross-linked from the resources they affect.

A resource collapsed into a group shape, such as Auto Scaling members or a Lambda name family, also gets a stratum with no shape of its own. Those sit alongside the drawn resources rather than under (Context).

A Continuum stratum's body tab is labelled Continuum rather than Overview. It holds a Resource table, a Details table, per-type tables, Tags, links to related strata, and the full payload in a collapsed Raw data disclosure. A Terraform drift tab joins it where state is reconciled.

What a sync preserves

Containers can grow to make room for additions without moving what is already inside them. Where a container is boxed in by authored content, Continuum places the addition in free canvas space and keeps its resource membership rather than moving your work.

A label or membership you have not customised follows the source. Anything you overrode wins. Managed shapes you deleted stay deleted once the diagram has recorded a refresh baseline. Older diagrams without that baseline preserve customisations conservatively, because a deletion made before the baseline cannot always be inferred.

New resources wait for you

A resource discovered after the first sync is not added to the diagram straight away. It is drawn on the notes layer with a green outline, and the settings cog's menu shows a running delta such as "+3 new".

Choose Promote N new resources from the cog to move them onto the blueprint layer. Until then they sit alongside the diagram rather than in it.

What the outlines mean

Drift takes precedence over lifecycle. These outlines come from cloud discovery only. A linked monitoring platform never changes a shape.

Changing the reading direction

Reading direction is not a control on the tab. Ask the AI assistant to reorder the diagram top down or left to right. It proposes the change and applies it only after you confirm.

Version restore is refused

Once a blueprint carries Continuum-managed content, restoring an older version of it is refused. A version snapshot never captured the connections and bindings behind those tabs and strata, so a restore would delete them with nothing to rebuild from. Remove the Continuum component and unbind those strata first. See versions and history.

Binding one shape instead

A shape you drew yourself can be tied to a single live resource. Add a stratum to it, open + Add tab and choose Continuum, then pick a connection, a region or location, and one resource. Pull now re-reads it.

AWS and Azure connections can both be bound. A Terraform-state connection cannot: "Only AWS and Azure connections can back a live stratum."

The control appears only for a signed-in editor on a Teams plan or above, on a rich stratum in a saved blueprint. Binding also needs cloud_connections.manage on the organisation or team that owns the connection; without it the picker reports no usable connections. Readers never see it.

Continuum Link attaches a saved snapshot from an operational platform to a stratum, as its own read-only tab. Alert state, service ownership and change context sit beside the thing on the diagram they refer to.

It needs an Enterprise plan, edit access to the blueprint, and continuum_integrations.manage on the organisation or team that owns the connection. Below Enterprise the engine refuses with "Continuum integrations are an Enterprise feature."

It never draws

Connect a platform

Open Settings → Continuum on the organisation or team, find Operational integrations, and choose New integration. The form asks for a Type, a Name, whatever non-secret fields that connector declares, and one credential. Choosing Connect & verify stores the credential and runs a handshake against the platform in one step.

Jira Cloud and Jira Service Management Operations replace that button with Connect with Atlassian and sign you in instead. Most other connectors take a pasted token or key, GitHub and GitLab included.

Two groups store no credential here. AWS CloudWatch reuses a verified AWS cloud connection: pick that connection and a region, and widen its role with the CloudWatch and Logs actions the form lists. The ten on-premise connectors keep their credential on the Continuum Local agent, and Blueprintr never stores it.

Credentials are encrypted at rest, are never returned to the browser, and are never written into a snapshot. The row afterwards shows a verification state and a bound-tab count.

Link an object to a stratum

Save the blueprint, open a stratum, and choose Continuum Link from its + Add tab menu. Search across every verified connection you can use, review the candidate's identity, then select Link object. The first snapshot is fetched before the binding is saved, so a link that would have failed never lands.

One connection holds one linked object per stratum. Selecting a different object from the same connection replaces that connection's binding. A stratum can carry 20 linked tabs; a twenty-first is refused with "This stratum already has the maximum of 20 integration tabs." Linked tabs do not count toward the 20 tabs you add to a stratum yourself.

In the blueprint editor a linked tab is read-only, because each re-fetch replaces its content. It can still be renamed. To delete it, remove its link.

These tools propose candidates instead of you searching:

Suggest Continuum Links lists every match it finds and ticks one for you only when its evidence is strong on its own and nothing competes for it. No second object from the same connection can match as closely, no other shape can claim the same object, and the shape's icon must not show a different kind of system. Nothing is ticked from a connection that failed for some shapes, from one whose index is out of date, incomplete or limited to some object types, or when a run finds more matches than it can compare, because a competing match could be missing. It never searches for a name that only describes a role, such as "Database" or "Web server", and it skips container names, text shapes and notes. Every other match is listed unticked with the reason it was held back.

A connection a stratum already links is not suggested for that stratum, because adding a second object from it would replace the first. For the same reason, once you add a match, other matches from that connection for the same stratum can no longer be added from the list.

None of these tools writes anything until you add a match, and a dismissed match is not suggested again. Suggestions read the last saved version of a diagram.

The button under a diagram says how many suggestions there are before you open it, for example "4 Continuum Link Suggestions Found". It counts every match the dialog would list, held-back ones included, and it drops as you add or dismiss them.

The suggestion index

So that Suggest Continuum Links can propose matches without asking your platforms, Blueprintr keeps its own index of what each connection can see.

What it stores

The name and subtitle of each object, under the same audience and detail settings that connection's panels follow, the link to it, and the reference Blueprintr uses to fetch it again. Identifiers such as hostnames, addresses, MAC addresses, serial numbers, asset tags and URLs are stored only as one-way digests, which can be matched but not read back. Alert state, incidents, metrics, panel content and credentials are not stored.

Who sees it

Only people who can already use a connection see matches from its index. The index is never shown as a list of its own; it only produces the suggestions you review.

When it updates

Every hour Monday to Friday between 09:00 and 17:00 UTC+2, and every six hours outside that window. A connection is also queued after you verify it, resume it, change its settings or its credential, and when an administrator chooses Update index. UTC+2 here is a fixed offset and does not follow daylight saving.

Indexed connectors

24 connectors are indexed: PagerDuty, incident.io, Rootly, FireHydrant, xMatters, Datadog, New Relic, Dynatrace, Elastic, Splunk Observability, SolarWinds Observability SaaS, Grafana Alerting, LogicMonitor, Auvik, Azure Monitor, Google Cloud Monitoring, Pingdom, Better Stack, UptimeRobot, Checkly, Site24x7, ServiceNow CMDB, GitHub and GitLab. Every other connector, including every connector served by the local agent, is checked live instead.

Some object types only

Seven of these connectors index only some of the objects a live check can return, so matches from their index are always held back for review and Check live asks those connections too:

Limits

An index holds at most 50,000 objects for one connection. A connection with more is marked incomplete.

Incomplete indexes

An index is also marked incomplete when the platform cannot be listed to the end, and when objects were left out because the reference Blueprintr keeps for them includes a URL with credentials or a secret parameter such as a token, for example a monitored web address. Such objects are skipped, never stored with the secret removed. An incomplete index keeps its matches held back until a later update lists the platform in full.

Empty listings

If a connection whose index has objects lists nothing, Blueprintr keeps the previous index and marks it incomplete. Only a second empty listing in a row replaces it, and that update waits for the normal schedule even when an administrator chooses Update index or verifies the connection sooner.

Held back

Matches from an index that is incomplete, or more than 12 hours old, are listed with that reason and never ticked for you, because a closer match may be missing from it. Check live asks those connections directly.

What it can and cannot find

The index reaches objects beyond the page limits a live search works within, so it can find matches a live check misses. A live check searches text the index does not hold, so it can find matches the index misses. Neither is a subset of the other.

When an index is deleted

Indexing switched off for that connection, the connection suspended, its token removed or replaced, its settings saved, a failed verification, a credential the platform rejects, the connection deleted, the plan lapsing (within about an hour), and seven days without a successful update. Database backups keep deleted rows for their retention period.

The index never writes to a blueprint. Adding a match still fetches a live snapshot through the same path as any other link.

Refreshing is manual

Opening a tab shows its saved snapshot and contacts nothing. Nothing polls a platform to update a tab, and no tab is refreshed on a schedule. The one thing Blueprintr runs on a schedule is the suggestion index, which proposes links and never changes a tab.

Each linked row has two icon buttons with no visible text. The circular-arrows icon re-fetches, and its tooltip reads "Re-fetch this integration's data". The broken-link icon removes the tab, with the tooltip "Remove this integration tab", and asks you to confirm.

A banner above every saved tab states which of these applies:

Ten connectors declare a freshness window: PagerDuty, incident.io, Rootly, Datadog, LogicMonitor, Auvik, Jira Cloud, Jira Service Management Operations, ServiceNow and GitHub. Most set five minutes. Jira Cloud work items and GitHub set fifteen, Jira Service Management on-call coverage sets two, and ServiceNow sets one day.

The banner is a reminder to refresh, never automatic polling.

The GitHub connector distinguishes an empty result from incomplete or unavailable reads. A repository metadata/identity failure preserves its previous snapshot; an enabled section failure is marked in a newly saved partial snapshot. Coverage and failure handling vary by connector; consult its guide before interpreting absence.

Who can read a saved panel

This depends on the connector, so check it before linking.

A connector in the last row has no audience setting, so its panel reaches every reader of the blueprint. On a public blueprint that includes anonymous readers, embeds and exports. The seven connectors in the first row offer a reader-visible option labelled All Blueprint readers; on four of them the full label adds "approved metadata".

An audience change applies to later fetches. It does not rewrite snapshots already saved, and it cannot recall versions, templates, exports, embeds or AI answers that already carry the data. Unlinking a tab and revoking a credential cannot recall them either.

Managing a connection

Deleting a connection is refused while tabs are still bound to it: "This integration has N stratum tab(s) bound to it. Remove those first."

If the plan lapses, the section stays open in a cleanup-only mode. You can suspend, inspect, unlink and disconnect. Adding or refreshing data needs Enterprise again, and the suggestion indexes for that owner's connections are deleted within about an hour.

Which platforms

39 connectors are registered. 29 work directly, and 10 more need the local agent for systems Blueprintr cannot reach.

The connector reference lists all of them with what each one asks for and shows. These have a guide of their own:

39 connectors are registered. 29 connect directly and 10 need the local agent. All of them are Continuum Link, so all of them need an Enterprise plan and continuum_integrations.manage, and none of them draws on a canvas.

Every connector can be found by free-text search when linking a stratum. Where a credential field has no label of its own, the form calls it API token.

Alerting and on-call

Observability

Monitoring

CloudWatch is the one cloud connector that stores no credential of its own. It reuses a verified cloud connection, so the form offers a connection and region picker instead of a token field.

That connection's role needs nine CloudWatch and Logs actions the discovery role does not grant. The form lists them under Required IAM actions for the backing role; add them before expecting alarm or log-group data. On an organisation-mode connection the form also asks for a 12-digit member account id.

Alertmanager always requires a secret to save the connection. For an unauthenticated instance, leave Username blank and type any placeholder in Password. It is never sent without a username.

Google Cloud Monitoring shows alert-policy configuration only. Its panel states "Open incidents unavailable".

Uptime and synthetics

Service management and source control

On-premise, through the local agent

These ten appear in the connector list but cannot be selected until the organisation has an enrolled agent online that can serve them. Until then the option is disabled and its label says why: set up an agent, the agent is offline, or upgrade the agent. Blueprintr never stores their credentials. Set in the agent's own configuration, a credential never leaves your network; sent from the Continuum Local panel instead (the agent must allow it), it passes through Blueprintr to the agent without being saved. The connection form has no credential field, and shows the account each product needs under its notice.

For SolarWinds Orion, Checkmk, Icinga 2 and Infoblox the username is part of the agent's credential, so the connection form does not ask for it. It shows what that account needs instead; set the username with the password, in the agent config or from the Continuum Local panel.

Each one wants a dedicated account that can only read, on a known port, and most need a certificate given to the agent. A port in the connector's URL replaces the default. The Continuum Local page explains the certificate column.

NetBox

Supports NetBox 4.0 and later; verify refuses an older release, because before 4.0 NetBox ignores the list of fields Blueprintr asks for and would send config contexts. Enter the token alone, without the word Token or Bearer. v1 tokens are 40 characters; v2 tokens (NetBox 4.5 and later) begin nbt_ and include the part after the dot. Either works. Blueprintr never asks for config contexts or comments. It asks for custom fields only when you list some under Custom fields to show; left blank, or set to none, no custom field value leaves NetBox. NetBox cannot send only some custom fields, so while any are listed, NetBox sends Blueprintr every custom field value on the device or virtual machine: panels show only the listed ones, and the rest are deleted with the request within minutes. A custom field named like a credential is never shown, even when listed. If you keep secrets in custom fields, leave the list blank. The panel is for Blueprint editors unless you choose all Blueprint readers.

Infoblox

Leave the WAPI version blank on NIOS 8.6 and later (2.12). The certificate NIOS installs with is issued to www.infoblox.com, so replace it with one for the Grid Master's address before giving it to the agent as caFile; the Continuum Local page has the steps. While any extensible attributes are shown, the grid sends Blueprintr all of an object's extensible attributes: panels show only the listed ones, and the rest are deleted with the request within minutes. Enter none and Blueprintr never asks for them. If you keep secrets in extensible attributes, use none. Panels are for Blueprint editors only, since leases and MAC addresses can identify people on client networks.

Veeam Backup & Replication

Needs version 12 or later and agent 0.2.0 or later, which keeps Veeam's access token on the agent. On 12.0, set the REST API version to 1.1-rev0. The build number in the verify message needs the Backup Administrator role, and is left out for a Backup Viewer. The tab measures a restore point's age on the backup server's own clock. A job that includes a machine through a folder, tag or cluster is found through the machine's restore points, not through the job definition. Panels are for Blueprint editors only.

Reading any panel

Whatever the connector, the same rules hold.

• Data is fetched with the connection's credential, not the reader's. A source link opens the provider, which applies its own permissions.
• A panel is a named projection of the provider's response. The raw upstream object is never stored as-is.
• A failed read never becomes a zero. Sections are marked unavailable or partial, and partial counts are lower bounds.
• A provider that cannot be reached leaves the saved snapshot in place. The tab keeps its last successful body and the banner reads "Last refresh failed". A first link that cannot fetch is refused, so no tab is created.
• A saved panel reaches everyone who can read the blueprint unless its connector has an audience setting or keeps its panels for editors. Datadog, LogicMonitor, Auvik, Rootly, ServiceNow, GitHub and NetBox have the setting, and Infoblox and Veeam Backup & Replication panels are always for Blueprint editors only. On a public blueprint every other panel is visible to anonymous readers, embeds and exports.
• 24 connectors are indexed so Suggest Continuum Links can propose matches without asking the platform: PagerDuty, incident.io, Rootly, FireHydrant, xMatters, Datadog, New Relic, Dynatrace, Elastic, Splunk Observability, SolarWinds Observability SaaS, Grafana Alerting, LogicMonitor, Auvik, Azure Monitor, Google Cloud Monitoring, Pingdom, Better Stack, UptimeRobot, Checkly, Site24x7, ServiceNow CMDB, GitHub and GitLab. The index holds object names, links and one-way digests of identifiers, under the same audience and detail settings. Datadog, GitHub, GitLab, incident.io, New Relic, ServiceNow CMDB and xMatters index only some of their object types, so their matches are held back for review and also checked live. Every other connector is checked live.
• Counts describe what was retrieved at the stated time. They are not a statement that the component is healthy now.

Link a PagerDuty technical service to the stratum for the component it covers. The saved tab shows who owns the service, what is open against it, and whether the primary escalation level had cover when it was fetched. Responding to incidents stays in PagerDuty.

A PagerDuty technical service is the only object that can be linked. Business services appear inside a service's panel as related rows, and cannot be linked on their own.

Connect

1. You need an Enterprise licence, edit access to the blueprint, and continuum_integrations.manage on the connection's organisation or team.
2. In PagerDuty, create a dedicated read-only REST API key under Integrations → Developer Tools → API Access Keys. An Events API integration key will not work here. If you paste one, Blueprintr sends it and PagerDuty rejects it with "PagerDuty services read failed (HTTP 401). Check or replace the REST API key."
3. In Blueprintr, open Settings → Continuum on the organisation or team, go to Operational integrations, choose New integration, and select PagerDuty as the Type.
4. Give the connection a Name, set the two options below, paste the key into API token, and choose Connect & verify. Without a name the form refuses with "Give this integration a name."

Connection options

Both dropdowns open on Use default, which stores nothing and behaves as the first real option.

Verification makes two list calls, one for services and one for incidents. Both may return nothing and still verify, so a successful check proves the key reads those collections, not that the account has content. On-call coverage and service dependencies are not exercised at verification time, so they may still fail when a service is linked.

Link a service

Open the stratum and choose Continuum Link, then search by any of these. PagerDuty has no prefix syntax.

A URL from the other region is refused rather than looked up: "This PagerDuty service URL belongs to a different region. Choose the matching connection."

What the panel shows

The headline restates PagerDuty's service status: "No open incidents reported", "Acknowledged incidents", "Triggered incidents", "Maintenance · new incidents suppressed" or "Disabled · new incidents suppressed". The Meaning row spells out the limit of that reading: "PagerDuty incident and notification state; not a measurement of component availability."

If the service read and the incident read disagree, the headline is replaced with "Service and incident state disagree · refresh to recheck" rather than showing a healthy state.

Counting and its limits

Open incidents are those PagerDuty reports as triggered or acknowledged, with no creation-date cutoff. Retrieval stops after five pages of up to 100, so roughly 500 incidents. When that cap is reached, the section title gains "partial retrieval", every count gains a trailing plus sign, and the Retrieval row reads "Partial: stopped after 5 pages; counts are lower bounds."

On-call coverage is computed over one hour starting at the fetch, filtered to the service's escalation policy. If those pages could not all be read, coverage reads Unknown rather than claiming a gap: "Coverage retrieval is partial; absence does not establish a coverage gap." A service with no escalation policy makes no on-call call at all.

Related services are limited to six detail lookups. Business services never carry a state, showing "Business impact not retrieved", because the connector does not infer business impact.

What is never imported

Responder names, user IDs, email addresses and schedule names are excluded in both content modes. So are incident bodies, assignees, acknowledgers, conference-bridge numbers, service integration keys and business-service points of contact. Detailed mode adds exactly two fields: the incident title, truncated to 250 characters, and the service description, truncated to 1000 characters.

Only pagerduty.com HTTPS links reach the panel, with query strings and fragments stripped.

Audience

PagerDuty declares no audience setting, so its saved panel is visible to everyone who can read the stratum. On a public blueprint that includes anonymous readers, embeds and exports. Service names, team names and relationships are visible even in Summary mode.

Choose Detailed only when incident titles and the service description are appropriate for that audience. Reducing detail later applies to subsequent refreshes and does not recall copies already shared.

Changing the region later

Changing the region is refused while any binding predates the region setting: "Remove the existing legacy bindings before changing PagerDuty region, then link services from the new region."

If every binding does carry a region, the change is allowed, and each of those services then fails on refresh with "This service was linked in a different PagerDuty region. Unlink it and choose the service again." The new region is verified with the existing credential before it saves, so a US-only key fails the switch to EU and the previous setting is kept.

Refreshing and recovery

Snapshots become due for refresh after five minutes, which is a reminder rather than automatic polling. A failed service or incident read keeps the previous snapshot and adds a warning; it never becomes a healthy zero. A failed on-call or dependency read marks only that section unavailable and still saves the panel.

Link an incident.io Catalog entry to the stratum for a service or component, and the tab shows the incidents that named it. Link an incident instead, and the tab explains one response: its lifecycle, severity, measured durations and follow-up state. Responding and writing up stay in incident.io.

Connect

1. You need an Enterprise licence, edit access to the blueprint, and continuum_integrations.manage on the connection's organisation or team.
2. In incident.io, create a dedicated key under Settings → API keys with View data (viewer) and View catalog (catalog_viewer). Leave write permissions and View all incident data (global_access) disabled.
3. In Blueprintr, open Settings → Continuum, go to Operational integrations, choose New integration, and select incident.io as the Type.
4. Paste the key into API key, set any of the optional fields below, and choose Connect & verify.

Verification reads the key's identity, one incident, the Catalog type list, one Catalog entry, the custom-field list when relationship fields are configured, and one follow-up when remediation counts are on. All requests are reads against api.incident.io.

Optional connection settings

Every field can be left blank. The three list fields accept up to 50 comma-separated IDs each. Ask your incident.io administrator for the stable IDs.

Active, triage and paused incidents are checked regardless of age, so the history window only bounds the recent-history count.

Link an object

Open the stratum, choose Continuum Link, and search. Once an incident.io connection is in play, an incident.io objects selector appears with Catalog and incidents, Catalog records and Incidents. Search a name, a stable ID, an INC number or an incident link.

Typing catalog: or incident: in front of a query narrows it the same way the selector does.

What is always excluded

Blueprintr applies its own filter before anything reaches a panel, whatever the key is permitted to read.

• An incident appears only when incident.io marks it organisation-visible and its mode is standard or retrospective. Private, test, tutorial and stream incidents never appear. Linking one returns "incident.io incident is private, unavailable, or a test record and cannot be linked."
• A Catalog type that represents people or customers is dropped, whether by its category or by user, person, customer, contact or employee appearing as a word in its name. Linking an entry of that type fails, but the reason is not shown. The editor sees the generic "incident.io could not be reached", so check the type's category and name before suspecting the connection.
• Only three shapes of Catalog attribute can be shared: numeric, boolean, and a relationship to a team, service or product-feature type. Free text is excluded. An attribute whose name suggests a secret, a token, an email address or a phone number is excluded even when its type is numeric, and selecting it fails verification.

Approved attribute values are clamped further: at most 10 records per attribute, numbers must parse as numbers, and a relationship label must be 160 characters or fewer with no line break and nothing shaped like an email address.

What a Catalog panel shows

The Coverage row states the limit of the reading: "Organization-visible standard and retrospective incidents only; private records are excluded. A related incident does not by itself establish component health."

The headline is one of: "Archived Catalog entry", "Related incident coverage incomplete", a count of related active incidents, a triage and paused count, or "No related active incidents in available scope".

What an incident panel shows

Reference, lifecycle, status, severity, whether a lead is assigned, and created and updated times. The lead row reads Assigned, Unassigned or Unknown, and never names the person. Below that sit measured durations with their availability, the incident's timestamps, and links out to the incident, the postmortem and any linked issue.

With remediation counts on, a Follow-ups section adds outstanding, completed, not-doing and unknown-status totals. Descriptions and assignees are not imported.

Partial results

Retrieval is bounded. When a page limit or budget is reached, counts are prefixed "At least", the panel adds a coverage-incomplete section, and the snapshot is marked partial. A count from a partial read is a lower bound, never a total.

Common messages an editor sees:

• "incident.io needs Catalog read access. Ask the connection owner to enable catalog_viewer and Verify in Settings → Continuum."
• "incident.io needs actions.view access for remediation counts. Enable that read permission or turn off remediation counts, then Verify."
• "incident.io results are incomplete. Narrow the Catalog types or search scope, then retry; open incident.io for the full view."
• "incident.io request limit reached. Wait a minute, then retry."

Audience and refreshing

incident.io declares no audience setting, so its saved panel reaches everyone who can read the stratum, including anonymous readers of a public blueprint. Incident references, names, severities and any approved Catalog attributes are visible to them. In incident.io, organisation-visible does not mean suitable for the public, so review a record before linking it.

Snapshots become due for refresh after five minutes, as a reminder rather than automatic polling. A failed refresh keeps the previous snapshot with a warning. Changing a setting applies to later fetches and does not rewrite copies already saved or shared.

Connect a Rootly service to the stratum for a system component, or link an incident to the stratum explaining a failure or recovery process. Readers can understand the response in the diagram's context and open Rootly for the full incident record. Blueprintr reads information; incident management stays in Rootly.

Connect and choose an object

1. You need an Enterprise licence, edit access to the blueprint, and continuum_integrations.manage on the connection's organisation or team.
2. In Rootly, open Organization Settings → API Keys → Generate New API Key. Prefer a dedicated Global API key assigned read-only Incident Response and, only if needed, On-Call roles. Personal keys inherit their creator's access; Team keys inherit Team Admin permissions. See Rootly's API-key guide.
3. In Blueprintr, open Settings → Continuum on the organisation or team, go to Operational integrations, and choose New integration. Select Rootly as the Type, give the connection a Name, enter the API key, review the audience and optional settings, then choose Connect & verify. Verification checks service and incident reads. There is no separate enable step.
4. Save the blueprint, open the relevant stratum, and choose Continuum Link. Search for the service or incident and review its identity before linking. Suggest integrations… on a shape and Scan for integrations across the blueprint both propose Rootly matches, and attach nothing until you apply them.

Blueprintr uses Rootly's hosted API at api.rootly.com. This connection does not provide an alternative regional or self-hosted endpoint.

Choose the information and audience

The baseline key needs read access to services and incidents. Context may also require team and environment reads; follow-up summaries need incident action-item reads. On-call coverage needs access to Rootly's on-call data and the relevant product entitlement. These are permissions on the key's assigned roles, not OAuth scope strings. Disable an optional capability instead of granting unrelated administrative access.

Rootly incidents marked private, or without a reliable privacy designation, are excluded from selection and saved incident data under either audience setting. Rootly's non-private designation does not itself make an incident appropriate for the public. Review titles, service names and relationships before switching to the reader-visible audience.

Read the snapshot

A service panel separates active response from recent history and maintenance. Normal incidents and sub-incidents are distinguished by kind; test incidents do not count as production incidents. The active view is independent of the 30-day history window, so an older unresolved incident can still be relevant. Maintenance has its own state and planned window when available; it does not become an outage merely because it is in progress. Rootly documents these filters in its incident API.

An incident panel shows response state, severity, related services and lifecycle times when available. Mitigated means impact has been reduced or halted; it does not mean response work is complete. Follow-up progress helps distinguish incident resolution from outstanding improvement work. Open Rootly to read descriptions, communicate with responders or change the record.

Opening a tab displays saved data. Re-fetch with the circular-arrows icon on the linked row, whose tooltip reads "Re-fetch this integration's data". Rootly snapshots indicate that another refresh is needed after five minutes; this is a freshness warning, not automatic polling. On-call coverage is limited to the time checked. Incident counts describe retrieved records, not a guarantee that the system is healthy.

Missing information and recovery

An unavailable incident list, incomplete pagination or unreadable optional section is shown as unavailable or partial, rather than as zero incidents or no outstanding work. If a whole refresh fails, the prior snapshot remains with a warning. Check the key's role and expiry; for rate limits, wait for the stated retry interval before refreshing again.

Rotate a credential with Rotate token, then Verify & replace, which swaps it only if the new key verifies. Suspend stops search and refresh while leaving saved snapshots readable, and Resume restarts it. The broken-link icon on the linked row removes the binding. The connection can be deleted after its bindings have been removed.

Copies and rollout checks

New snapshots restricted to editors use Blueprintr's existing audience controls for readers, embeds, viewer exports and search/AI indexing. Editor exports and backups retain the source. Approved reader-visible snapshots follow the blueprint's audience, including anonymous readers of a public blueprint.

Settings apply to subsequent fetches. Changing the audience does not rename existing Strata or link labels, or remove authored notes outside the managed panel. Review those separately before relying on a narrower audience. Templates, version history, exports and other existing copies are not retroactively rewritten or recalled by an audience change, key revocation or unlink.

Before operational rollout, verify the connection against your Rootly account: service membership, a known older active incident, maintenance, private-incident exclusion, optional permissions and on-call coverage. Local fixture tests do not establish your account's entitlements or replace this live check.

Blueprintr connects to Atlassian three separate times, for three separate jobs.

The first two are Continuum Link connectors. The third is a write path and is covered at the end of this page.

Connecting

Both read connectors are created only through Atlassian sign-in. On the New integration form, choosing either provider hides the Name field, the config fields and the secret field, and offers Connect with Atlassian instead. Pasting a token is refused: "Connect this integration through Atlassian sign-in."

After consent you choose an Atlassian site, name the connection, and decide the counts-only setting. Only sites that granted every required scope are offered. If none did, you see "No Jira Cloud site granted the required access. Check the app's permissions and your Jira membership, then reconnect."

Scopes requested are fixed per connection:

Blueprintr verifies the connection with a read before saving it, and creates no test issue. A connection's site cannot be edited afterwards: the row offers Reconnect with Atlassian rather than Configure, and reconnecting is pinned to the original site.

Counts-only

A checkbox on the site-selection page reads "Import counts and operational state only. Omit work item summaries, alert subjects and query details from blueprint snapshots."

It removes the free text from both the rendered tab and the stored payload:

Candidate titles also become neutral, such as "Jira work item" and "JSM alert scope", which is what a stratum minted by Scan is named.

Searching Jira Cloud work items

The syntax hint appears on the connection row in settings, not in the stratum search box: "Link a work item, filter:123, epic:PROJ-123, or jql: followed by a query."

Queries are capped at 2,000 characters. A link from a different Atlassian site is refused without making a request: "This Jira link belongs to a different site. Choose that site's integration."

A query panel reads at most 250 work items. Past that, the count is a lower bound and the panel says "Showing at most 250 matching work items. Open Jira for the full result."

A bound work item shows work item, type, project, status, status category, priority, resolution, due date and last update, plus parent, components, target versions and related work when present. A missing value reads "Not set or unavailable" rather than a healthy default. Descriptions, comments, assignee and reporter are never fetched.

Searching Jira Service Management Operations

The hint on that connection row reads "Search entity or subject text, query: for an Operations query, team: or schedule:."

Queries are capped at 1,000 characters.

An alert panel makes two independent reads on each refresh: current open alerts matching the saved query, up to 500, and a separate newest-15 history page. A large volume of newer closed alerts therefore cannot hide an older open one.

The headline follows a strict order. Any open P1 or P2 makes it critical. An unknown priority or an incomplete read makes it "open alerts · status incomplete". Zero open alerts reads "No open alerts in this query" only when retrieval was complete, every priority was known and nothing else warned; otherwise it reads "No open alerts · recent history unavailable". Partial results never read as an all-clear: the Coverage row says "Partial retrieval; this is not an all-clear" and counts are prefixed "At least".

An on-call schedule panel reports schedule, owning team, counts of current people on call, current team and escalation routes, next people on call, timezone and when it was checked. Individual responder identities and contact details are never returned or stored. Where routing is by team or escalation only, the status reads "On-call routing configured; person coverage unconfirmed" rather than naming anyone as on call.

Freshness and audience

Neither connector sets an audience, so both panels reach everyone who can read the blueprint, including anonymous readers of a public blueprint, embeds and exports. Counts-only is the control for that exposure, and it applies from the next refresh onward rather than rewriting saved snapshots.

Creating a Jira follow-up from a stratum

Configure a Jira destination on the organisation's Settings → Continuum page. Choose + New webhook, set the destination to Jira, then choose Connect Jira account to sign in with Atlassian a second time and grant write:jira-work.

Pick the project, work type and required fields, then use Verify without creating a work item before saving. The work type must have Description on its Jira creation screen, or the destination is refused. Every required field on that screen without a Jira default must also be given a value here.

The Jira follow-up button then appears in the stratum tab strip for an author who can edit the blueprint and holds webhook.manage on the owning organisation. A blueprint with no owning organisation never shows it.

The dialog is titled Create Jira follow-up and asks for a destination, a summary of up to 240 characters prefilled as "Follow up: ", and what needs to happen, up to 12,000 characters. Create Jira issue submits it. Your own submission is the approval step; nobody else reviews it. The text is recorded durably before Jira is contacted, so a retry cannot create a second issue, and reusing a request with different text is refused.

The created issue links back to the stratum. Its key can then be linked through the Jira Cloud connector to follow progress.

New destinations create follow-ups manually only. Automatic creation is opt-in and limited to four events: a blueprint being published, and a workflow run being submitted, approved or rejected.

Connect Datadog to the Stratum for a component on your diagram. Use a host to explain telemetry reporting, a monitor to explain an evaluated condition, a catalog service to explain ownership and dependencies, or an SLO to show performance against an objective. Open the linked Datadog record for detailed investigation and operational changes.

Connect

1. You need Enterprise, edit access to the Blueprint, and continuum_integrations.manage on the connection's organisation or team.
2. Create a dedicated Datadog service account with read permissions. Under Datadog credentials, set Credential type to API key and application key, or to Service Access Token and fill that field. A Service Access Token pasted into the application-key box is rejected. Follow Datadog's key setup or Service Access Token guide.
3. In Blueprintr, open Settings → Continuum on the organisation or team, go to Operational integrations, choose New integration, select Datadog as the Type, enter a Name, and choose the Datadog site. If you use a custom Datadog domain, find the underlying site in My Preferences. See Datadog sites.
4. Review the information and audience settings, enter credentials in the labelled password fields, and choose Connect & verify. Blueprintr stores credentials encrypted and never displays them after saving.

Hosts and monitors require hosts_read and monitors_read. Enable optional capabilities only when needed:

Catalog versions use distinct APIs. Choose the one your account uses and verify availability on your site. Datadog sites are independent and product availability differs. The connection reads existing information; it does not create monitors, SLOs, public dashboards or new telemetry instrumentation. Your existing Datadog entitlements and API limits still apply.

Choose the component's operational context

Save the Blueprint, open its Stratum, and choose Continuum Link. Search by host or monitor name, paste a Datadog monitor, SLO or infrastructure source link, or use one of these forms:

Review the connection, stable identity and source preview before linking. Catalog and SLO searches require the corresponding connection option. Linking a Datadog service requires its exact env tag value, without spaces or wildcards. For other Catalog entity kinds the field reads Environment (optional) and may be left blank. The service identity and deployment environment serve different purposes; changing a deployment's version tag does not make it a new service. Unified service tagging explains Datadog's service, env and version relationships.

Add an explicitly selected SLO ID to a service and choose its window. Check that the objective describes this service and environment: a similar name is not proof of that relationship. Standalone SLO selection also lets you choose 7, 30 or 90 days, where supported by the objective.

For a multi-alert monitor, optionally copy the exact Datadog group string to show that group's state. Without a group, the panel describes the monitor's aggregate state. One monitor may cover many hosts or environments; its aggregate alert is not proof that every component is affected.

Scan and Suggest offer matches for review. Use manual search when you want to choose an environment, SLO or monitor group. Each connection has one managed tab per Stratum; choosing a different object explicitly replaces its binding. Authored prose and diagram content stay intact.

Read the saved information

Host reporting means whether Datadog received the expected metrics. Missing telemetry is not proof that a host is down. Hosts outside Datadog's available inventory window can become unavailable. Monitor panels retain distinct alert, warning, no-data and other provider states; these are evaluated conditions, not a general guarantee of system health.

Catalog v3 separates declared relationships from those Datadog discovers through APM or Universal Service Monitoring. If provenance cannot be established, it is labelled unknown. These relationships are catalog-wide; the selected monitor environment does not filter this topology. The earlier Service Definitions API supplies ownership and links, with no relationship retrieval. Catalog navigation opens your regional Software Catalog; use the displayed entity identity to locate the component. Structured operating links may include documentation, runbooks and dashboards recorded on the selected entity. Blueprintr does not discover every dashboard or publish dashboard contents.

SLO panels show the objective's target and calculated performance for the selected window. Error budgets retain their units and may be negative when the budget is exhausted. Blueprintr never substitutes 100% for an unavailable calculation. Datadog's own no-data rules still apply: monitor SLOs follow the underlying monitors' settings, and time-slice SLOs count no-data periods as uptime. The panel explains these limits. See Datadog's SLO history and monitor details.

Opening a tab displays its saved snapshot. Re-fetch with the circular-arrows icon on the linked row ("Re-fetch this integration's data"). Snapshots show their retrieval time and become due for refresh after five minutes; this is a freshness warning, not automatic polling. Incomplete retrieval is labelled partial. Counts from a partial list are lower bounds; an unavailable section does not mean zero. A failed refresh keeps the previous snapshot with a warning.

Information and audience

New connections default to Blueprint editors and Summary. Summary retains the identity and operational measures while keeping monitor detail to a minimum. Detailed mode can include monitor names and approved tag values; new connections approve only service, env and version tag keys initially. Enter none to omit tags; clearing a configured list also omits tags on the next refresh. Monitor messages, notification recipients and raw telemetry are omitted.

Choose the reader-visible option, All Blueprint readers, whose full label adds "approved metadata", only after reviewing the information for that audience. A public Blueprint can have anonymous readers who do not authenticate to Datadog. Host identities, service names, ownership, links and even selected tag values may be confidential.

A connection created before these settings existed has no stored value for audience, saved detail or approved tag keys. Each absent value resolves to its legacy behaviour: blueprint readers, detailed, and every tag key up to 30, excluding keys whose name suggests a secret. Such a connection publishes monitor names and all tag values to everyone who can read the blueprint.

Opening Configure and saving unchanged keeps that behaviour, because the form pre-selects the legacy values. Select Blueprint editors under Datadog content audience, choose Summary under Saved detail, set Approved tag keys or enter none, choose Verify & save settings, then refresh each linked tab. Settings affect subsequent successful refreshes; they do not rewrite existing snapshots. Editor-only panels follow the shared reader, embed, viewer-export and search/AI audience controls. Editor exports and backups can retain the source data. Names in authored notes or link labels outside the managed panel need separate review.

Unlinking, reducing detail, revoking credentials or changing audience does not recall saved versions, templates, exports, AI answers or copies already shared.

Recovery and disconnection

Verification checks the required reads and enabled optional capabilities. Host and monitor reads must pass. If an enabled Catalog or SLO check fails, the connection stays usable for hosts and monitors and the verification notice shows which optional access needs attention. After reloading settings, use Verify to recheck optional availability; the stored verified status alone does not establish it. If access is denied, check the site's selection, credential expiry and exact read permissions. Scoped keys do not inherit extra permissions. Newly created keys can take a few seconds to propagate. For rate limits, wait for the stated retry interval before refreshing; see Datadog's rate-limit guidance.

Use Verify & replace for credentials. Replacing an application key while keeping the same API key preserves links. Changing the API key or Service Access Token requires reviewing and linking objects again, because Blueprintr cannot assume the new credential addresses the same account. Changing sites also requires relinking. Older bindings must be unlinked before these changes. A failed credential verification preserves the previous credential.

Suspend stops search and refresh while retaining snapshots, and Resume restarts it. The broken-link icon on the linked row removes the binding and its managed tab. Remove all bindings before deleting a connection. Remove its stored credential and revoke it in Datadog when access should end.

Before operational rollout, validate your site's permissions, known host and monitor groups, missing telemetry, large result sets, SLO calculations, optional Catalog availability and regional source links against your own account. Local fixtures do not establish live product availability or account entitlements.

Link a LogicMonitor device, DataSource instance or resource group to the Stratum for the component it describes. A server can show the conditions affecting it; a circuit can show the exact monitored interface; a site can show the observed state of its group members. Keep your explanation alongside the saved observation. Investigation, alert acknowledgement and configuration changes remain in LogicMonitor.

Connect your portal

1. You need an Enterprise licence, blueprint edit access and continuum_integrations.manage on the connection's organisation or team.
2. In LogicMonitor, create a dedicated API-only user. Assign a role with Resources View on only the resource groups Blueprintr should read. Device, group, alert, instance, metric and scheduled downtime reads use resource permissions. Write, alert acknowledgement and Collector settings permissions are unnecessary. See Resources role permissions.
3. Create a Bearer API token for that user. This connector accepts Bearer tokens. LogicMonitor also supports LMv1 authentication, but an LMv1 access ID/key pair cannot be pasted into this connector's Bearer field.
4. In Blueprintr, open Settings → Continuum on the organisation or team, go to Operational integrations, choose New integration, select LogicMonitor as the Type, and enter a name, company and Bearer token. For https://acme.logicmonitor.com, enter acme as the company.
5. Review the content audience, saved detail and optional settings below, then select Connect & verify. Verification checks resource and alert reads with the supplied credential. A successful check with no visible devices is explained separately: review the user's resource-group access or add monitored resources. Verification does not establish complete coverage or verify every optional read. Save the blueprint before adding a link.

This connection uses REST v3 on commercial logicmonitor.com portals. The portal host is always built as <company>.logicmonitor.com, so LMforGov portals and custom API hosts cannot be reached. No local agent is required. Credentials are encrypted and are not displayed again after saving. LogicMonitor documents the supported authentication methods in its REST authentication guide.

Choose the object your diagram describes

Open the Stratum for your server, interface or site and choose Continuum Link from its + Add tab menu. Only a rich stratum can host a linked tab. Search its name, hostname or IP, or paste a current UIv4 device or group resource URL from the portal. Review the connection, company, object type, stable ID and instance lineage before choosing Link object, especially when names repeat. A successful first fetch is required before the binding is saved. One connection can have one linked object on a Stratum; selecting another explicitly replaces that connection's previous link.

Scan and Suggest can help match diagram identifiers. Every suggestion still needs your review. Search results are limited to what the dedicated LogicMonitor user can read; no match does not prove that the object does not exist. Resolve any reported search or coverage warning before relying on absence.

Choose detail, scope and audience

These settings belong to the connection. Detail, audience, maintenance and datapoint changes apply to subsequent fetches. The group scope is saved with the selected object: review and relink a group to change its scope.

Existing connections keep their historical reader-visible detailed behaviour until an administrator chooses otherwise. Existing settings with no maintenance option do not enable additional maintenance reads.

Alert messages, acknowledgement comments, arbitrary resource properties and Collector configuration are not imported. Summary information still includes resource identity and operational metadata: it is not anonymous. Datapoint names and availability vary by DataSource; choose names meaningful to the interface or component rather than assuming every instance provides the same metrics. The instance API and data API describe this resource hierarchy.

Read the saved observation

The panel distinguishes active alert severity, collection availability and maintenance. Detailed snapshots also show acknowledgement and the affected DataSource, instance and datapoint. Acknowledgement means someone has acknowledged an alert; it does not mean the condition has recovered. Scheduled downtime can suppress notifications while monitoring continues. A Collector problem means the resource's current observations may be unavailable. None of these states should be read as a general guarantee of system health. See LogicMonitor's scheduled downtime rules.

Alerting flags describe the object's local setting. The panel does not resolve every inherited group or DataSource alert-suppression rule; check the provider when deciding whether notifications should be sent.

Maintenance windows on an instance panel describe its parent device and can include other monitoring scopes; they are not all specific to the selected instance. A group panel reads schedules for the selected group, without individually retrieving schedules for every member device or child instance. Use each alert's downtime flag and the portal for precise maintenance scope.

Counts describe the active alerts and resources retrieved within the connection's permissions and selected scope. If pagination cannot be completed, the panel marks its coverage as partial; do not treat a lower bound as the full total. Unknown, missing or unreadable information is not zero. Last NetFlow receipt, if displayed, describes NetFlow specifically and does not establish the freshness of all monitored data.

Optional instance metrics request the past hour and show the latest 12 samples per selected datapoint, together with the requested/returned windows, sample interval and missing-data information. Summary mode uses generic metric labels; Detailed mode includes the selected datapoint names. Metric samples are never labelled with a unit. The value column is headed "Value (unit unspecified)" and the Units row reads "Unit not supplied by LogicMonitor; untransformed provider values". Blueprintr shows the raw numbers without inferring a unit, converting the value or deriving a rate. Consult the DataSource definition in LogicMonitor to interpret the sample correctly.

Opening the Stratum displays a saved snapshot and does not call LogicMonitor. Re-fetch with the circular-arrows icon on the linked row ("Re-fetch this integration's data"). After five minutes, the snapshot indicates that another refresh is needed. This is a freshness reminder, not automatic polling. Each metric has its own sample time; fetching a panel now does not make an older provider sample current.

Use the source link to continue investigating the selected device, group or instance in LogicMonitor. A link does not grant access: the provider still applies the signed-in user's own permissions. Extended graphs, alert messages, acknowledgement and configuration remain in the portal.

Recover from failures and disconnect

A failed required read does not become an empty, healthy observation. A failed refresh keeps the previous snapshot and shows a warning. An optional section that cannot be retrieved is marked unavailable or partial. Check resource permissions and token expiry, then verify the connection again. For rate limits, wait before retrying; repeated browsing and refreshes consume the portal's API capacity.

Use Verify & replace to rotate a token. The replacement is verified before it replaces the working credential. Suspend stops search and refresh while saved snapshots stay readable; Resume restarts it. The broken-link icon on the linked row removes the current binding; delete the connection after its bindings have been removed. Moving to a different portal requires reviewing and relinking object identities; device IDs are not portable between companies.

Sharing and retained copies

Provider data is fetched with the connection's credential. Readers are governed by the configured Blueprintr audience, not their individual LogicMonitor permissions. Approved reader-visible content can reach anonymous readers of a public blueprint, embeds, exports and configured search or AI features. Editor-only panels use Blueprintr's existing audience controls for those reader surfaces; editor exports and backups retain the source.

Changing a setting affects later successful fetches. Restricting the audience does not rewrite panels already saved: refresh each linked tab successfully, or unlink it, before treating existing LogicMonitor content as editor-only. It does not redact independent versions, templates, exports or copies already shared. Unlinking, suspending or revoking a token cannot recall those copies. Authored Stratum names, link labels and notes remain your content and need a separate audience review.

Validate before operational rollout

Automated tests exercise simulated provider responses; they do not establish that a particular LogicMonitor tenant grants the expected access. Before relying on this integration operationally, verify a least-privilege token, duplicate names, an exact instance, direct and descendant group membership, multi-page results, special-character searches and a permission-denied read in a representative portal. Confirm metric units and gaps, scheduled downtime, source links, freshness reminders and the published-reader audience. Check rate limits and any feature entitlements with that tenant. The integration does not import LogicMonitor topology or create monitoring configuration.

Link an Auvik Network Management device to the stratum for a switch, firewall, server or other component in your diagram. The saved panel helps readers identify the device, understand its network context and review recent alert events. Open Auvik for its current dashboards, detailed investigation and operational actions. Continuum Link does not redraw the diagram.

This connection uses Auvik Network Management. It does not import Auvik SaaS Management applications, users, licences or security logs.

Connect and select sites

1. You need an Enterprise licence, edit access to the blueprint and continuum_integrations.manage on the connection's organisation or team.
2. Create a dedicated Auvik service account with a custom API-only role and access to the intended sites. Give it read access to API – Device info, API – Alerts and API – Tenants. Auvik's built-in Read Only role does not grant these API permissions, and its built-in API Access Only role grants unrelated reads and tenant editing. Build a custom role with only the reads listed above. See Auvik's service-account guidance.
3. In Auvik, open My Profile → Manage API Credentials and generate the key. In Blueprintr, open Settings → Continuum on the organisation or team, go to Operational integrations, choose New integration, and select Auvik as the Type. Give the connection a Name, then enter Region, Username and the API key.
4. Review Auvik snapshot audience, Saved detail and the optional sections, then choose Connect & verify. To restrict the connection to named sites, select Configure on its row afterwards and open Auvik site scope. Clear Include every accessible site, choose Load Auvik sites, tick the sites, then choose Verify & save settings. Ticking a site does not save it on its own. Exact site IDs accepts up to 25 comma-separated leaf-site IDs instead. Changing the region or username requires saving and verifying again before the site list will load.
5. Save the blueprint and open the relevant stratum's Continuum Link controls. Search by device name, IP address, serial number or stable Auvik API ID and review the site, identity and matching evidence before linking. Suggest integrations… on a shape and Scan for integrations across the blueprint both offer candidates; selecting one is still an editor decision.

Include every accessible site includes current and future sites accessible to the Auvik service account. Clear it and select exact sites to keep a connection focused on one customer or environment. The list uses Auvik's site labels or domain prefixes alongside stable IDs. Selecting a parent organisation is not a substitute for selecting its leaf sites. Device names and private IP addresses can repeat across sites: check the site and stable device ID before attaching a panel.

Verification checks inventory and alert access for each explicitly selected site. Optional capabilities are checked on one representative site; the result names that site. The first fetch and later refreshes check the actual linked device and available data, so a verified connection can still have unavailable optional observations on another device or site.

Choose the saved information

Optional sections can be unavailable because of account permissions, discovery coverage or product availability. They do not require write access. Ask the Auvik administrator to grant the specific read permission or leave the section off; granting an administrative role is unnecessary.

Read the panel in context

The device status is Auvik's observation at the fetch time. An online device can still have a fault, and a device marked unmanaged is not evidence of monitoring coverage. Missing information means unknown or unavailable, not healthy.

Alert history contains events that Auvik recorded during the selected window. Created, resolved, paused and unpaused events retain their meanings. A created event is not presented as proof that its alert is still active. Dismissal and dispatch are separate properties. Use the event's source link to check the current record in Auvik when using Detailed mode; Summary retains event counts and the device's dashboard link. The detailed timeline shows the most recent 20 retrieved events, and the scope states which interfaces were included. Detailed mode also caps the network membership table at 20 networks and the address list at 12, each with a coverage row stating what was omitted.

Interfaces distinguish whether a port is administratively enabled from its observed operational state. An administratively disabled port is different from a failed uplink. Peer and network relationships describe Auvik's discovered inventory; they do not establish that a route is reachable or that redundancy will work.

Maintenance information helps prepare a replacement or change. A backup timestamp does not prove that a restore will succeed. Lifecycle information can include Auvik's information provider, confidence and source links; review those sources before treating a predicted end-of-support date as a vendor commitment.

Performance observations cover the previous 24 complete UTC hours with hourly samples. The panel states its period and units; missing hours remain gaps, and an hourly average is not an instantaneous measurement or a service availability guarantee.

Refresh and recover

Opening the tab shows its saved snapshot. Re-fetch with the circular-arrows icon on the linked row ("Re-fetch this integration's data"). After five minutes the snapshot is due for refresh; this is a reminder, not automatic polling. A failed refresh retains the previous snapshot with a warning. An unreadable or incomplete optional section is labelled rather than turned into zero alerts or a successful check.

If access fails, check the account's API role, selected sites and region. An Auvik account move can require a new region. Unlink every linked Auvik device before changing it: "Unlink existing Auvik devices before changing region, then review and link their identities in the new region." For a rate limit, wait before refreshing again. Choose Rotate token on the connection's row, then Verify & replace, which verifies a replacement credential before it swaps. A replacement is refused when more than 50 linked Auvik identities need checking; Suspend stops search and refresh while leaving snapshots readable, and the broken-link icon removes the current binding. Delete a connection after removing its bindings.

Site or credential changes must preserve access to existing links. If a new scope excludes a linked site, keep it selected or unlink that device first. Older links without a saved site identity need to be reviewed and linked again before their scope or credential identity can change.

Sharing and retained copies

The panel is fetched with the service account's access. Readers do not need their own Auvik account to see an approved reader-visible snapshot. Opening a source link still requires their own Auvik access.

Editor-only panels use Blueprintr's existing audience controls for readers, embeds, viewer exports and search/AI indexing. Approved reader-visible content follows the blueprint's audience, including the public on a public blueprint. Editor exports and backups can retain the source information.

Settings apply to later fetches. They do not retract previous exports, version history, templates or other independent copies, or redact authored titles and notes outside the managed panel. Review those separately before publishing. Revoking a key, suspending a connection or unlinking does not recall existing copies.

Before operational use, compare a known device and its history with your own Auvik account, confirm the selected sites and optional permissions, and check the reader view. Some Auvik API capabilities are documented as beta. Local tests do not establish your account's access or live data completeness.

Link a ServiceNow configuration item (CI) to the stratum for the component it records. The saved tab shows what the CMDB believes about that component: its class, lifecycle, environment, the groups that own and support it, when Discovery last saw it, how it relates to other CIs and, if you choose, the open incidents and changes recorded against it. Changing the record stays in ServiceNow.

Any record in cmdb_ci or a class that extends it can be linked: servers, network gear, application services, business applications. IP-address and network-adapter records are found too, but rank below the device with the same name.

Connect

1. You need an Enterprise licence, edit access to the blueprint, and continuum_integrations.manage on the connection's organisation or team.
2. In ServiceNow, create a dedicated integration user. Give it the cmdb_read role, which reads every CMDB table. If the instance enables the REST API ACL, add snc_platform_rest_api_access as well. Tick Web service access only on the user, and keep it out of any policy that demands interactive multi-factor authentication: the connection signs in with the password on every call and cannot answer a prompt.
3. In Blueprintr, open Settings → Continuum on the organisation or team, go to Operational integrations, choose New integration, and select ServiceNow CMDB as the Type.
4. Enter the Instance URL (https://acme.service-now.com, reachable from the public internet), the Username, and the password, set the options below, and choose Connect & verify.

Connection options

Each dropdown opens on Use default, which stores the first option.

Verification reads one record from each table the connection will use: cmdb_ci, cmdb_rel_ci, and with open work switched on, incident and change_request. A table the user cannot read fails verification with its name and the role that grants it, for example "The ServiceNow account cannot read cmdb_rel_ci (HTTP 403 Forbidden). Grant cmdb_read, plus snc_platform_rest_api_access when the REST API ACL is enabled."

Open work needs sn_incident_read and sn_change_read from the ITSM Roles plugin, or itil. Those roles may count as a fulfiller licence on your instance; check with your account team before granting them.

On a domain-separated instance the user sees only its own domain, and so does the tab.

Link a configuration item

Open the stratum and choose Continuum Link, then search by any of these.

Each result shows its class, IP address, location and lifecycle, so two records with the same name can be told apart, and its sys_id in the preview.

Scan and Suggest resolve hostnames, FQDNs, IP addresses, serial numbers and MAC addresses from the diagram. Identifiers of one kind are folded into a single query of up to 50, so a full site drawing costs a handful of reads.

What the panel shows

The headline reads the install status and operational status together, for example "Installed · Operational". ServiceNow keeps the two fields independently, so a record retired through install status is shown with a warning even while its operational status still says Operational. On order, in stock, in maintenance, repair, standby and ready states are shown as informational. The CSDM lifecycle stage appears as its own row.

Environment is the record's own environment field. Older records that only set the legacy "Used for" field show that value instead.

Dates come from the stored value and are labelled UTC. If an instance returns only display values, the date is shown as ServiceNow formatted it, without a zone label.

Counting and its limits

Relationships stop at 25; the section title then reads "Relationships (25 of 61)". Open incidents and changes are read up to 25 each; the count states how many were retrieved when the total is higher.

What is never imported

Person fields (owned by, managed by, assigned to, attested by), comments, work notes, incident and change descriptions, and any custom column. Only the named columns are requested, and the saved data is projected from them, so a column the instance returns anyway never reaches the blueprint.

Audience

New connections save snapshots for blueprint editors only. Choose All Blueprint readers only when the class, ownership, relationships and, in Detailed mode, the addresses and serials are appropriate for everyone who can read the blueprint. Changing the audience applies to later refreshes and does not recall copies already shared, exported or answered by AI.

Refreshing and recovery

Snapshots become due for refresh after one day, which is a reminder rather than automatic polling. A failed CI read keeps the previous snapshot and adds a warning. A relationship read or task read that fails marks the panel incomplete and says which table could not be read; the rest of the panel still saves. A rate limit answered by ServiceNow with Retry-After is reported with the number of seconds and is never retried in a loop.

Link the repository behind a component to its Stratum. Choose the branch, workflow, issue labels, deployment environment and source path that explain that component. Your diagram stays the starting point; GitHub provides dated evidence and links for further investigation.

Connect repository reads

1. In the owning organisation or team, open Settings → Continuum → Operational integrations → New integration, and select GitHub. Continuum Link needs an Enterprise plan and continuum_integrations.manage on the connection owner. Linking a repository later also requires blueprint edit access.
2. Create a fine-grained personal access token for the intended resource owner and selected repositories. Obtain any required organisation approval. Use a dedicated integration credential with an expiry you can maintain. GitHub sign-in does not grant repository access to Link.
3. Enter a Repository to verify, as owner/repository or its GitHub HTTPS link. This is a verification sample; other linked repositories are checked when selected. An optional Organization restricts discovery and linking to that owner. Without one, the suggestion index keeps the names of every repository the token can list. Set an organization, or limit a fine-grained token to selected repositories, to narrow it.
4. Choose the reads to enable and grant their corresponding permissions below. Keep Blueprint editors only and Summary unless the wider content and audience are appropriate. Paste the token and choose Connect & verify.

Contents permission also grants access to code, so turn it on only for the commit and release rows. Link does not create issues, run workflows or change the repository. Verification checks each enabled read, not only that the token is valid. Empty accessible lists are valid. This path supports GitHub.com; GitHub Enterprise Server and GHE.com are not supported. See GitHub's permission reference.

Choose the context for a component

Save the blueprint and open Continuum Link from the Stratum's + Add tab menu. Search a repository name, paste owner/repository, or paste its GitHub.com URL. A child URL such as an issue or pull request selects its containing repository, not an individual work item. Scan and Suggest also propose repository links for you to review.

Open Choose the context for this component before linking:

One connection can bind one repository/context to a Stratum. Re-select and link it to change the context. The repository's numeric ID protects against an old name being reused for a different repository. An old link without sufficient identity evidence asks you to re-select before it can refresh.

Read the evidence

Issues and pull requests appear separately. GitHub's repository-wide open count is explicitly labelled issues + PRs. Open-work lists retrieve up to 300 records per section and display at most ten; coverage distinguishes exact matching counts, bounded samples and unavailable reads. Run history shows up to ten entries; deployment evidence shows up to three attempts and their latest reported statuses. GitHub's issue-list retrieval limit includes PR records that are removed from the issue section. PR label counts are exact only when the queried PR list was retrieved in full. Missing information is not a healthy zero.

Opening the tab shows a saved snapshot. Use the circular-arrows button to fetch again. After fifteen minutes the snapshot asks for a refresh; it does not poll. If repository identity or metadata cannot be read safely, the previous snapshot is preserved. If an enabled issue, workflow or optional section fails, the new snapshot marks that section partial or unavailable; it does not present old section values with a new timestamp.

Summary retains identity, visibility, states, scope and links but omits work titles and descriptions. Detailed adds repository descriptions, issue/PR titles and workflow names. Neither mode imports issue bodies, comments, commit messages, personal identities, workflow logs, deployment payloads or release notes.

Create and recover a follow-up

An organisation administrator with webhook.manage configures a separate GitHub Issues destination by choosing its card in Settings → Continuum. Choose the owner and repository and supply a separate fine-grained token with Metadata: read and Issues: read and write. Optional existing labels need repository push access. Verify without creating an issue checks access and configuration; only a real creation can prove that GitHub accepts the write.

An editor who also has the organisation's webhook.manage permission can choose GitHub follow-up on a saved Stratum, review the issue title, description, repository visibility and source link, and create the issue. Repository readers may differ from blueprint readers. Only the reviewed issue text, source title/link and delivery reference are sent. The outcome and issue link remain available from that Stratum.

GitHub Issues belongs to the Webhooks & workflow family advertised for Team. Its organisation permissions are separate from the Enterprise plan required for Link reads.

New destinations are manual-only. Optional subscriptions cover blueprint publication and review submission, approval and rejection. They send a minimal event summary, not arbitrary blueprint content or review comments. Existing destinations must verify and save once to establish repository identity.

Delivery history distinguishes queued, retrying, failed, successful and unknown outcomes. Safe retries are scheduled. An interrupted create with an unknown outcome is not blindly repeated: find the issue in GitHub and reconcile it by issue number in delivery history. Older one-shot deliveries are not replayed automatically.

Sharing, recovery and other GitHub paths

Newly fetched Link data defaults to blueprint editors, including when an older connection has no audience setting. Choosing All Blueprint readers makes approved snapshots available to everyone who can read the blueprint, including anonymous public readers, embeds, exports and configured search/AI features. GitHub does not re-authorise each Blueprintr reader. A source link still requires that person's own GitHub access.

Settings apply on the next fetch. They do not rewrite earlier snapshots, versions, templates, exports or distributed copies. Unlinking or revoking a token cannot recall those copies. Review content before sharing it.

Use Configure to adjust permissions/content and Verify & replace to rotate a token. A replacement must retain access to existing linked repository IDs and enabled reads before it replaces the working token. For access errors, check repository selection, token expiry, organisation approval and SSO. For rate limits, wait before retrying. Suspend stops new searches and refreshes; unlink tabs before deleting a Link connection.

Folium repository sync is a separate docs-as-code path, configured on an individual Folium. Review the exact destination and selected pages before pushing; draft and hidden pages start unselected. GitHub sign-in is another independent path and grants no Link, issue-creation or Folium-sync permissions.

Alert state from a linked monitoring platform appears on a stratum, as a saved panel. It never appears on the drawing.

On the stratum, not the canvas

Shape outlines do change, but they come from Continuum Cloud discovery, not from monitoring. A red outline means the cloud provider reports the resource offline, not that something is alerting. The full vocabulary is on keeping diagrams true.

To see where in a system a problem sits, open the stratum for the component. The diagram gives it its context; the panel gives it its state.

Who can read it

The saved panel travels with the stratum. It is stored in the blueprint's own record and in backups, and unless the connector restricts its audience to editors it reaches everyone who can read the blueprint, including anonymous readers of a public blueprint, embeds and exports.

Among the alerting and monitoring connectors, only Datadog, LogicMonitor, Auvik and Rootly can restrict it, and a new connection to any of them starts restricted. A Datadog or LogicMonitor connection created before the setting existed stays reader-visible until an administrator changes it. Check the connector before linking an alerting platform to anything published. See Continuum Link.

What a panel is

A dated snapshot, fetched when an editor asked for it. Opening the tab displays what was saved and contacts nothing.

Read the banner above it before acting on the numbers. It says whether the snapshot is current, due a refresh, incomplete, failed or paused. An incomplete snapshot reports lower bounds, and a failed read is labelled unavailable rather than shown as zero.

Counts describe what a platform reported at a stated time. They are not a statement that a component is healthy now.

Finding which platform knows about a shape

Each aid needs an Enterprise plan, edit access, and at least one verified connection. Below that they refuse or do not appear.

Suggest Continuum Links under a Vellum diagram's bottom bar checks every shape on the blueprint against Blueprintr's index of your connections, and the button says how many matches it found before you open it. The same button on a stratum's tab strip checks one stratum: its linked shape, its title, and hostnames, addresses or URLs in its text. Check live in either dialog asks the connections themselves instead, a batch of shapes at a time. Matches with strong, unambiguous evidence start ticked. The rest are listed with the reason they were held back, which includes an index that is out of date, incomplete, or limited to some object types. A connection a stratum already links is not suggested for that stratum again. See Continuum Link for what the index stores and when it updates.

Right-click a shape in a saved diagram and choose Suggest integrations…. It scores matches from the shape's identifiers, its icon, and whether a connected shape is already bound to the same platform.

On Resources & Strata in the blueprint editor, the scan button reads Scan · N integrations once connections exist. It reads stratum titles, file content, tab bodies and shape labels, up to 200 identifiers per scan.

All of them propose candidates for review and attach nothing until you add or apply them.

Not a monitoring system

Blueprintr does not evaluate conditions, hold thresholds, or page anyone. It reads state from the system that does, and links back to it for anything you need to act on.

Continuum Local is an agent you run inside your own network. It exists so Continuum Link can read monitoring systems that are never exposed to the internet, and so you can sweep your network for SNMP devices.

It is the on-premise half of Continuum Link and sits behind the same gate: the organisation that owns the agent needs an Enterprise plan (a team's agent uses its parent organisation's plan), and you need continuum_integrations.manage on that organisation or team.

What it serves

It serves SolarWinds Orion, Zabbix, PRTG Network Monitor, Checkmk, Icinga 2, ManageEngine OpManager, WhatsUp Gold, NetBox, Infoblox and Veeam Backup & Replication, whose fields and panels the connector reference lists. Each appears in the connector list but stays disabled until an agent that can serve it is online. The label says why: set up an agent, your agent is offline, or upgrade your agent. An agent counts as online when it has checked in within about ninety seconds.

Each one needs a dedicated account that can only read. The credential parts are the names you use under credential in the agent's configuration, or in the send credentials form.

A port you give in the connector's URL replaces the default, including 443 for a reverse proxy. WhatsUp Gold and Veeam Backup & Replication trade the username and password for an access token, which the agent keeps: Blueprintr only sees a stand-in for it. They need agent 0.2.0 or later, and the connector list says to upgrade an older agent.

How it reaches Blueprintr

The agent dials out over HTTPS on port 443. Nothing connects inward, so no inbound firewall rule is needed. Allow outbound HTTPS from the agent's host to blueprintr.io and agents.blueprintr.io. The agent keeps a connection open to agents.blueprintr.io when Blueprintr offers it, polls at least once a minute, and falls back to polling blueprintr.io directly if that connection stops answering. A proxy for this traffic is set with proxy and noProxy in the agent's configuration.

There is no schedule of its own for connectors. A job is created when an editor refreshes a linked tab, and a queued job expires if no agent claims it.

Blueprintr's suggestion index never covers these connectors, so nothing about your on-premise systems is copied to Blueprintr ahead of time. Suggest Continuum Links reaches them only when an editor chooses Check live, and then through the agent, like any other request.

Getting the agent

Download it from the Continuum Local download page while signed in to an account on an Enterprise plan. The Continuum Local panel links there too. The page offers the current release and a few earlier ones, so you can install the version your change control approved or roll back to one.

Installing covers packages for Debian and Ubuntu, RHEL, Rocky and Alma, and Windows Server, each with its own runtime, plus a container image, a Helm chart and a single file for a host with Node.js 24. Every release is signed, and Releases and verification gives the signing identity to check it against.

Registering an agent

Register it yourself from Settings → Continuum → Continuum Local on the organisation or team.

New token and Re-enroll issue a replacement token and cancel the previous unused one. Neither works on a revoked agent: create a new agent instead. Revoke cuts an agent off at once, including a connection it has open.

If the organisation's plan has lapsed, enrolment is refused with a message that says so, and the token is not spent. Once an owner renews the plan, restart the agent and it enrols with the same token while the token is still valid.

After a lapse the panel still lists the agents, marked as paused, so you can take them out of service: Revoke, Delete (which also deletes the agent's network sweep results) and remove from agent for credentials sent from Blueprintr. Nothing else is offered until the plan is active again. A paused agent's polls are refused, so remove from agent usually reports it offline. Remove those credentials on the agent's machine instead, by deleting its state as described under Uninstall.

Credentials

Blueprintr never stores a credential for an on-premise system. The security model lists where the agent keeps each kind. Blueprintr cannot read, export or recover a credential, and cannot help you rotate one. Rotation happens in the agent and in the monitored system.

A credential sent from Blueprintr passes through Blueprintr over an encrypted connection to the running agent, which keeps it in its own state directory. Blueprintr keeps no copy, so nothing is queued: the agent has to be online and connected to agents.blueprintr.io at the time, and the panel shows it as "connected through the gateway". An agent that is only polling cannot receive a credential, and where Blueprintr does not offer the gateway, the panel says sending credentials is not set up. In either case, put the credential in config.json.

• remoteCredentialScope in the agent's configuration limits which hosts Blueprintr may configure. Certificate settings sent from Blueprintr are refused unless that scope sets allowTlsOverrides.
• A connection set in config.json always wins. Blueprintr can neither replace nor remove it.
• remove from agent deletes a credential Blueprintr sent. Deleting the connection in Blueprintr removes it from the agent too. Both need the agent online and connected to the gateway, so remove credentials before you revoke or delete an agent.

Revoking or deleting an agent in Blueprintr, or uninstalling it, does not delete what is on its machine: config.json and any credentials sent from Blueprintr stay there until you delete the agent's configuration and state, as Uninstall describes for each platform.

Wherever the credential is set, Blueprintr runs the connector with unguessable placeholder values standing in for it, and tells the agent which parts to replace with local values. The agent refuses to send a request if a placeholder survives into it, and for a credential set from Blueprintr it will only reach the host that integration is configured for.

Read-only by default

The agent sends only requests it recognises as reads for that product, by the rules of its read-only guard. Anything else is refused with operation_not_allowed, and nothing is changed. Blueprintr's message says which check refused the request, and Operation not allowed gives the fix for each.

Setting "allowWriteOperations": true on one integration in config.json lifts the guard for that integration only. Blueprintr can never set it. Upgrade the agent first, and turn it on only for a write you have confirmed you want to allow.

Network sweeps

With a discovery block in its configuration, an agent can sweep your network for SNMP devices. Start one from Network sweeps below the Continuum Local panel, or schedule one daily or weekly. The agent sweeps only the ranges in its own discovery block: Blueprintr can narrow a sweep to some of them but never widen it, and the SNMP credentials stay on the agent. An agent runs one sweep at a time.

Blueprintr keeps the devices, ports and links each sweep finds for 90 days from when the sweep starts, apart from each agent's latest complete sweep, which is kept until a newer one completes.

Certificates

The agent refuses a certificate it cannot verify. Orion, PRTG, OpManager and Veeam Backup & Replication install with a self-signed certificate, and Icinga 2 uses its own certificate authority (ca.crt in /var/lib/icinga2/certs). For Checkmk, Zabbix, WhatsUp Gold and NetBox it depends on how they were installed; NetBox serves no HTTPS of its own, so it is whatever sits in front of it. Give the agent that certificate, or your internal authority's, as caFile rather than disabling certificate checking.

Infoblox NIOS is the exception. It installs with a certificate issued to www.infoblox.com, so caFile alone cannot verify it for your grid's address. Replace the grid's certificate first: in Grid Manager, go to Grid > Grid Manager > Members, select the Grid Master, and choose Certificates > HTTPS Cert > Generate Self-signed Certificate for the address the agent uses (an IP address goes in as a subject alternative name; on an HA pair, use the address of the VIP), or install one from your own certificate authority. Then give the agent that certificate as caFile. Turn checking off with allowInsecureTls only as a last resort.

Compatibility

The agent advertises what it can do, and Blueprintr sends only work that matches. A newer kind of job is invisible to an older agent rather than breaking it, so agents upgrade on your schedule rather than Blueprintr's. The panel shows Update available when a newer release exists. Before version 1.0 only the latest release is supported.

Troubleshooting

When an agent has not been heard from for 15 minutes, Blueprintr emails the owners and admins of the organisation that owns it, and of the team for a team's agent. On the agent's host, run continuum-local check, then read the agent's log and look up any error code in Troubleshooting, which also says where each install writes its log.

Continuum Local ships as Debian and RHEL packages, a Windows installer, a container image, a Helm chart, and a single JavaScript file for a host that already runs Node.js. Every format runs the same agent file. Install the format your estate already manages, give it an enrolment token from Blueprintr, run continuum-local check, then start it.

Before you start

Sizing

The agent runs up to four relay and probe jobs at a time (maxConcurrentJobs, 1 to 16) and one network sweep alongside them. It ships with these limits:

Run one copy of each agent. Two processes sharing one enrolled identity take work from the same queue, which adds no redundancy. For another site or network segment, create another agent. An organisation or team may register up to 25 agents, and a revoked agent counts until you delete it.

Download and verify

Download from the download page while signed in to an account on an Enterprise plan; for anyone else the page reports not found. Check the signature before you install. The page prints the commands for the release you are viewing, and Releases and verification explains them.

The commands below use $V for the version you downloaded, for example V=0.2.0.

Linux packages

Debian and Ubuntu

sudo apt install ./continuum-local_${V}_amd64.deb
sudo cp /etc/continuum-local/config.example.json /etc/continuum-local/config.json
sudo -e /etc/continuum-local/config.json
sudo chown root:continuum-local /etc/continuum-local/config.json
sudo chmod 640 /etc/continuum-local/config.json
sudo continuum-local check /etc/continuum-local/config.json
sudo systemctl enable --now continuum-local

On arm64, install the _arm64.deb. What to put in config.json is under Enrol the agent. The package creates a continuum-local system account and a systemd unit, and leaves the service disabled until you enable it.

RHEL, Rocky and Alma

sudo dnf install ./continuum-local-${V}-1.x86_64.rpm

On arm64, install the .aarch64.rpm. Then follow the Debian steps from cp onwards.

What the packages install

The service runs as the unprivileged continuum-local account, with no capabilities and a read-only filesystem apart from its state directory. Its logs are in the journal: journalctl -u continuum-local.

Run the continuum-local command with sudo. As root it reads /etc/continuum-local/environment the way systemd does, then switches to the continuum-local account, so check sees the same proxy, certificates and file permissions as the service.

Proxy settings

Put proxy variables in the environment file, or set proxy and noProxy in config.json, which take precedence:

sudo -e /etc/continuum-local/environment

HTTPS_PROXY=http://proxy.corp.example:3128
NO_PROXY=localhost,.corp.example

sudo systemctl restart continuum-local

The agent sends only its traffic to Blueprintr through the proxy. Its connections to your own systems stay direct. If the proxy re-signs TLS, set the proxy's root certificate as extraCaFile in config.json: the agent trusts that file for Blueprintr and never for your own systems. Variables used in env: references also go in the environment file, such as SOLARWINDS_PASSWORD for "password": "env:SOLARWINDS_PASSWORD".

Windows

Copy-Item "C:\Program Files\Continuum Local\config.example.json" `
  "C:\ProgramData\Continuum Local\config.json"
notepad "C:\ProgramData\Continuum Local\config.json"

& "C:\Program Files\Continuum Local\runtime\node.exe" `
  "C:\Program Files\Continuum Local\continuum-local.mjs" `
  check "C:\ProgramData\Continuum Local\config.json"

Set-Service -Name ContinuumLocal -StartupType Automatic
Start-Service -Name ContinuumLocal

The installer gives C:\ProgramData\Continuum Local its own access list: the service reads config.json but cannot change it, and writes only to state\ and logs\. Service logs are in C:\ProgramData\Continuum Local\logs. Set a proxy with proxy and noProxy in config.json, because environment variables added to the service are replaced on every upgrade.

Docker

docker run -d --name continuum-local --restart=unless-stopped \
  -v /etc/continuum-local:/etc/continuum-local:ro \
  -v continuum-local-state:/var/lib/continuum-local \
  ghcr.io/blueprintr-io/continuum-local:$V

The image runs as the unprivileged node user (uid 1000) and reads /etc/continuum-local/config.json, so uid 1000 needs read access to that file on the host. The continuum-local-state volume keeps the enrolled identity. Without it, a new container enrols again and fails, because the token is already spent. Check the configuration with the same mounts:

docker run --rm \
  -v /etc/continuum-local:/etc/continuum-local:ro \
  -v continuum-local-state:/var/lib/continuum-local \
  ghcr.io/blueprintr-io/continuum-local:$V check

Give a proxy as -e HTTPS_PROXY=... -e NO_PROXY=..., or in the configuration. Once you have verified the image, run it by the digest that cosign verify prints: a tag can be moved, a digest cannot.

Kubernetes

kubectl create secret generic continuum-local-config --from-file=config.json
helm install agent oci://ghcr.io/blueprintr-io/charts/continuum-local \
  --version $V --set existingSecret=continuum-local-config

To install from a file instead, use continuum-local-helm-chart-<version>.tgz from the download page in place of the oci:// address.

The chart runs one replica with the Recreate strategy, as a non-root user with a read-only root filesystem, and creates no Service or Ingress. Its main values:

Without existingSecret or config, the agent does not start. After you edit the Secret, restart the agent:

kubectl rollout restart deployment/agent-continuum-local

A host with Node.js

Requires Node.js 24 or later. Download continuum-local-<version>.mjs, write config.json beside it, owned by the account that runs the agent with mode 0600, then:

node continuum-local-$V.mjs check ./config.json
node continuum-local-$V.mjs ./config.json

Run it under whatever supervises long-running processes on that host. It exits cleanly on SIGTERM or SIGINT.

Configuration and state locations

The state directory contains the enrolled identity (agent-state.json, mode 0600) and any integrations configured from Blueprintr. statePath in the configuration overrides it on every format. Without it, the agent uses CONTINUUM_LOCAL_STATE_DIR when set, then a systemd StateDirectory=, then %ProgramData%\Continuum Local\state on Windows, then /var/lib/continuum-local for /etc/continuum-local/config.json on Linux, and otherwise the configuration file's own directory.

Enrol the agent

{
  "apexUrl": "https://blueprintr.io",
  "displayName": "DC1 agent",
  "enrollmentToken": "the token you copied"
}

An expired, spent or revoked token gets the same refusal. Issue another with New token on the agent, or for a revoked agent, create a new agent. If the owning organisation's plan is inactive, enrolment is refused with a message that says so, and the token is not spent.

Next, add your on-premise connections in Blueprintr and copy the configuration block the panel prints for each into integrations: see Continuum Local. Every setting is in the configuration reference.

Running the check

Run continuum-local check on every new install, after every configuration change and before you contact support. It tests the configuration, the state directory, the certificate roots, the route to Blueprintr and a TLS handshake with each integration host, without enrolling or spending the token.

Continuum Local makes outbound connections only. It listens on no port, so it needs no inbound firewall rule and no public address. The Helm chart creates no Service and no Ingress.

Outbound connections

An agent uses the gateway only after Blueprintr has advertised it, and polls blueprintr.io before that. Allow both hosts, so the agent can move to the gateway without a firewall change. The agent does not depend on the gateway. If it cannot open the WebSocket, it keeps working by polling. If the gateway stops answering polls, the agent polls blueprintr.io and tries the gateway again every five minutes.

The agent never downloads or updates itself. You install each upgrade.

On-premise systems

Allow TCP from the agent's host to each system's API port. A port you write in the connector's URL in Blueprintr replaces the default.

allowedHosts in the agent's configuration matches host names only, and any port on a listed host is allowed. Control ports with your firewall. The agent follows at most three redirects, and checks each one against allowedHosts again.

Network sweeps

A sweep sends SNMP GET, GETNEXT and GETBULK requests over UDP from the agent's host to port 161 on each address it probes, and needs the replies back. Sweeps are IPv4 only, and the discovery settings limit them. The agent sends at most discovery.packetsPerSecond packets a second (50 by default), shared by every sweep and probe it runs. It does not use ICMP or scan ports. Your intrusion detection sees SNMP requests from the agent's address.

Proxies

Traffic to Blueprintr can go through an HTTP or HTTPS proxy. Set proxy and noProxy in config.json, or HTTPS_PROXY and NO_PROXY in the agent's environment. The configuration file wins. Without it, the agent reads HTTPS_PROXY, then https_proxy, then HTTP_PROXY, and NO_PROXY, then no_proxy.

• Enrolment, polls, sweep uploads and the gateway WebSocket go through the proxy. It must allow a CONNECT tunnel to port 443 on both Blueprintr hosts.
• Connections to your on-premise systems and SNMP sweeps never use the proxy, whatever HTTPS_PROXY says, so an internal host name is never sent to it.
• SOCKS proxies are not supported.
• For a proxy that needs a user name and password, write http://user:[email protected]:3128. The password is masked in every log line. Put the URL behind env: or file: to keep it out of config.json.
• A proxy needs Node.js 24 or later. The packages and the container include it. The bare bundle on an older Node.js refuses to start with a proxy configured, rather than going direct.

Where to put the setting:

TLS-inspecting proxies

A proxy that re-signs TLS shows the agent its own certificate for blueprintr.io, and the agent refuses it until it trusts the proxy's root. Give the agent that root certificate, in PEM form, as extraCaFile. The agent trusts that file for Blueprintr only, never for your on-premise systems, because a proxy's root can sign a certificate for any name.

• trustSystemCa, on by default, trusts the operating system's certificate store as well. A proxy root already installed there works without extraCaFile.
• Avoid NODE_EXTRA_CA_CERTS for a proxy's root. Node.js reads it itself and trusts it for every connection, your on-premise systems included.
• A DER file is refused at start. Convert it with openssl x509 -inform der -in proxy-root.cer -out proxy-root.pem.
• A proxy that inspects TLS must also let the WebSocket upgrade to agents.blueprintr.io through. If it does not, the agent polls instead.

Firewalls and allow-lists

• Allow the Blueprintr hosts by name. Blueprintr publishes no fixed IP addresses for blueprintr.io or agents.blueprintr.io, and the addresses behind them can change. A firewall or proxy that filters on DNS names or on the TLS server name can allow them.
• Requests to your monitoring systems come straight from the agent, never through the proxy. If a system limits its API to certain source addresses, add the address the agent's traffic leaves from.
• Devices that limit SNMP to named managers need the agent's address in that list.

Checking the route

Run continuum-local check on the agent's host, with the command Troubleshooting gives for each platform. It resolves each Blueprintr host, opens a TCP connection and a verified TLS handshake, through the proxy when one is set, and does the same directly with every host an integration may reach, on port 443 unless you pass --port. It sends nothing beyond the handshake.

The agent reads one JSON file, config.json, when it starts. The file is the agent's security policy: it decides which integrations exist, which hosts each may reach and which networks may be swept. The agent never writes to it, and a change takes effect when the agent restarts.

Keys that start with // are comments. The Continuum Local panel in Blueprintr prints the block for each integration, keyed by its ID, ready to paste under integrations (see Registering an agent).

How the agent reads the file

• A value of the wrong type stops the start with a message that gives the key. Nothing is guessed: "true" in quotes is refused where true is meant.
• An unknown key at the top level, inside an integration or inside remoteCredentialScope is logged as a warning, with the key it probably meant, and the agent starts. Inside discovery, an unknown key is ignored without a warning, except inside collectors, where it stops the start.
• null counts as not set for top-level, integration and remoteCredentialScope keys.
• A syntax error is reported by line and column only. The agent never prints the text around it, which could be a credential.

{
  "apexUrl": "https://blueprintr.io",
  "displayName": "DC1 agent",
  "enrollmentToken": "env:CONTINUUM_LOCAL_TOKEN",
  "integrations": {
    "<integration ID from the Continuum Local panel>": {
      "provider": "solarwinds",
      "allowedHosts": ["orion.corp.example"],
      "caFile": "/etc/continuum-local/corp-root-ca.pem",
      "credential": {
        "username": "svc-blueprintr",
        "password": "env:SOLARWINDS_PASSWORD"
      }
    }
  }
}

Agent settings

A value outside what the table allows stops the start, except pollWaitMs, which is clamped. A relative file path resolves against the directory config.json is in.

A file given as extraCaFile or caFile must contain at least one PEM certificate. An unreadable file, or one with none, stops the start, and a DER file is refused with the openssl command that converts it. An expired certificate, or a private key in the same file, is logged as a warning.

Integration settings

Each entry under integrations:

An allowedHosts entry that contains a wildcard, a scheme, a user name, a path or a port stops the start. Any port on a listed host is allowed. Write IPv4 addresses in plain dotted-decimal form: 010.0.20.5 and 10.1 are refused, because resolvers read them differently. IPv6 addresses may be written with or without brackets.

A part the connector needs but cannot find fails the request with credential_missing, and the message gives the part's name.

remoteCredentialScope

This block limits integrations sent from Blueprintr, and has no effect while allowRemoteCredentials is off. A host in such an integration must match at least one entry.

With or without a scope, loopback, link-local (including the cloud metadata address 169.254.169.254) and unspecified addresses, and localhost names, are refused for integrations sent from Blueprintr unless a cidrs entry covers them. With allowRemoteCredentials on and no scope, the agent warns at every start that such an integration may reach any host that is not loopback or link-local. A scope with no entries refuses every one.

Discovery