-
Notifications
You must be signed in to change notification settings - Fork 7
Library and Blueprints
redStackPRO has two kinds of starting point, and both are blueprints: shipped blueprints you load from the canvas, and published blueprints in your Library, where your own saved topologies live and where you can offer one as a blueprint for your team to clone. A blueprint is always a read-only starting point; you clone it into your own private topology. This page is the one place that explains what each button actually does.
The Load blueprint button, and the Defense blueprints (GOAD family) and Offense blueprints in the palette, open a shipped starting point, not something stored in your account.
- Defense blueprints, GOAD and the rest, load locked. Everything you can normally do, drag, connect, delete, resize, edit in the inspector, is disabled so the baseline stays intact while you explore it. Click Unlock to edit when you are ready to customize.
- Offense blueprints load already editable, since they are meant as a base to grow from rather than a fixed reference range.
Either way, loading a blueprint never touches the shipped file. It only opens an unsaved draft in the canvas. Press Save and you get a brand new, fully private topology of your own: the blueprint stays exactly as shipped, ready for the next person to load fresh. Once you have saved once, Duplicate makes another private copy with no link back to the original.
Save stores your current topology privately in your account. It appears under Your topologies in the Library, you own it, and it stays fully editable. Saving again on the same topology adds a new version; the version number is shown next to its name.
Publish, from the Library's Your topologies list, takes one of your own saved topologies and offers it as a blueprint: a read-only starter that anyone on your org can clone into their own private copy. Your original is untouched and stays exactly as it was, still listed under Your topologies, still yours to edit and re-save.
Publishing shares within your org, not with the public at large.
The shipped open source tool has no operator identity or org boundary of its own. The running instance trusts the local caller and is single-tenant: on SQLite, or on the single-instance Postgres profile, "your org" is everyone who uses that one instance. Anyone reaching that instance sees the published blueprints and can clone them. There is no per-operator isolation and no authenticated login separating one user's Library from another's on a shipped instance. Per-operator isolation and authenticated, multi-tenant access are part of the enterprise edition. If you need publishing to be scoped to specific people rather than to whoever can reach the instance, do not rely on the shipped build for that boundary.
Unpublish takes it back out of the blueprint list. It has no effect on anyone who already cloned it; a clone is an independent copy from the moment it is made.
Use this, on any blueprint in the Library, always makes a new private copy that you own and can edit. This is true whether the blueprint is one a teammate published or your own: cloning never lets you edit the shared blueprint directly, only your own copy of it.
Save (private) -> Publish (share as a blueprint) -> others Clone (their own private copy)
Saving keeps a topology to yourself. Publishing turns it into a shared starting point without giving anyone write access to it. Cloning is how someone else turns that starting point into something they own and can change.
By default the Library has no seeded starter blueprint. It fills up only as people save their own topologies and publish some of them for the team. redStack (the recommended attack infrastructure stack) is available as an Offense blueprint in the palette, the same way GOAD is available as a Defense blueprint: load it from Load blueprint, it is not a seeded blueprint waiting in the Library.
See Concepts for how blueprints and topologies fit into the rest of the schema, and Getting Started for loading your first blueprint.