docs / Saving and Storage

Saving and Storage

Where your models are kept, and what to know about the browser's copy of them.

This page covers the file-based app. When the app is connected to a PLM server, documents are revisions on that server instead: see Connecting the CAD app.

The model document

A model document contains its feature history — the recipe, not the display mesh — plus document metadata, the active workbench, any embedded parts library and the assembly constraints. Saving writes that document; opening restores the workbench and replays the history. Imported geometry can still make it large: flat STEP/IGES imports keep their source text, and structured assembly parts carry exact native B-rep payloads. The document is saved as a .nbrep file — JSON text inside — and the model export and import trade the same file.

The shared File menu drives it: New part, New family, New template, Open, Save, Save As. Its recent-document rows, listed under the menu's two columns, reopen stored documents directly; each row shows a thumbnail of the document, rendered at every save through any store (browser storage, a native folder or a PLM server) and kept locally beside the recent list. A document saved before thumbnails existed shows a neutral square until its next save. The standard document actions are also available on Ribbon's Home tab and in the Classic primary toolbar. Open shows the in-app file explorer, the same on desktop and in the browser.

A document is a normal part (.nbrep), a family (.fbrep) or a template (.tbrep). The extension carries the class through every save and open, and New and Save As choose it. See Families and Templates.

Several models at once

Every open model gets its own tab on the 3D view pane, labelled with its file name. Exactly one model is active at a time: the tab you click is the model the viewport draws and every panel — History, Scene, BOM, Constraints, Expressions — shows. That tab bar holds 3D views and nothing else: no panel can be dropped into it, and no model tab can be dragged out of it.

New and Open add a tab. Nothing is replaced, so neither asks about unsaved changes.
Opening a model that is already open focuses its tab instead of opening it twice. For the same reason, Save As refuses a name another tab already holds.
The on a tab closes that model. A tab with unsaved changes (its name carries a •) asks before closing — the only place unsaved work can be dropped. Closing the last tab leaves a new empty model behind.
Each tab keeps its own camera pose, selection, undo history and workbench, so switching to an assembly brings the assembly panels with it. Display settings — theme, UI scale, colours, wireframe, and the perspective / orthographic projection — are global.
Reopening the app does not restore the previous session's tabs: every launch starts on a fresh model, so a problematic document cannot rerun itself the moment you restart. Which models were open is not saved. Saved models come back through Open; a document with unsaved changes is autosaved to a recovery record and offered back at the next launch as a prompt, never reloaded on its own.

To skip the Recover unsaved work? prompt on launch, check Settings → Display → Startup → Disable recovery dialog on startup. This preference is saved across launches. Autosaving stays enabled; existing recovery copies are left in storage until new autosaves replace them. Uncheck the option to show recovery offers again.

Each open model holds a complete scene of its own, so a second large assembly costs roughly what a second window would.

Where documents live

Desktop — real files. The explorer starts in the application's models directory, but can browse to and save in other filesystem locations. Exports (STEP, meshes, drawings, the BOM, a plugin bundle, a script) ask where too: the same explorer, as a Save file chooser that remembers the last export folder.
Browser — the browser's own IndexedDB storage for the site, in the database brep-app. Nothing is uploaded anywhere: the models are on that machine, in that browser, for that site.

Your settings, the dock layout, and the explorer's pinned locations use the same storage. On desktop they are reserved files in the application's configuration directory, alongside (not inside) its default models directory; in the browser they are separate records in the same IndexedDB database.

Clearing site data for the app, using a different browser, or using a different machine means an empty model list. To move a model, or to keep a copy outside the browser, use Export → Model (.nbrep) — in the browser that is an ordinary download — and bring it back with Upload…, the button the Open explorer shows in the browser.

Several tabs of the app

The app can be open in more than one browser tab, and every tab of the same site shares one set of saved models. Save a part in one tab and the other tabs pick it up while they are open: the next time you go to Open, or to Insert component in an assembly, the part is there, with no reload. A model deleted in one tab likewise leaves the others' lists. An assembly holding an older copy of a part you just re-saved elsewhere reports it as outdated, as it would if you had saved the part in that same tab.

Each tab keeps its own window layout, settings and open-tab set while it runs, so two windows arranged differently do not fight over one layout. They are saved to one shared record, so the next launch starts from whichever tab saved them last.
If you save the same model from two tabs at once, the last save to reach storage wins. Nothing merges them.

On desktop this does not arise: documents are ordinary files, read from disk each time they are used.

Browser storage is IndexedDB

Browser storage used to be localStorage, which browsers cap at roughly 5–10 MB per site — smaller than a single imported model: the native payload from one STEP import measured about 35 MB. IndexedDB has no such small ceiling.

Models saved by an older build are not carried over

There was no migration. Models saved in localStorage before the change do not appear in the model list. They have not been deleted — they are still in that browser's localStorage, under brep-app:model:<name> keys — but nothing in the app reads them. The durable way to carry a model across this kind of change is the .nbrep export.

If browser storage is unavailable, the app says so

There is deliberately no fallback to a smaller store. When IndexedDB cannot be brought up — for example, because storage is blocked for the site — the app still starts and works, but nothing persists:

a red notice appears immediately, before you have saved anything, saying that this session will not be saved and to keep your work by downloading it;
Save appears to succeed, because the session's in-memory copy is real and everything you saved this session stays openable within it — but another red notice, naming the document, appears for every save that did not reach storage;
closing or reloading the tab loses all of it.

The notices are the transient cards at the bottom of the window and fade after a few seconds, but every failed save produces one. If you see them, export the model (Export → Model (.nbrep)) before you close the tab.

The same notice appears for an individual failed write in a working session — for instance when the site's storage quota is exhausted. A save that did not persist is never silent.