📦 Importing and Exporting a Module

Beyond exporting your final application (already covered in the Export, Monetization category), Celestory lets you export a single module or an isolated graph to a file, to archive it or move it into another project. This guide describes what that file actually contains, how to import it elsewhere, and what happens on a naming conflict.

🚪 Where to Find It

Open the project menu, Project entry, then the Import/Export modules button at the bottom of the screen. A dedicated window opens, with a checkable tree (modules, each one's start graph, and any other graphs not attached to a module) and two buttons: Import and Export.

🗂️ What the Exported File Contains

The Export button produces a ZIP archive, named after the project and today's timestamp. Inside it:

• a data.json file describing everything you checked: the modules, the graphs and their blocks, the linked variables, each module's configuration, and the editor's version number at export time;
• a files/ folder holding the binary files actually used by your selection (images, including a Chatbot module's character portraits).

🔺 So this is not just logic: the referenced assets (files used inside the blocks and inside the module's configuration) are genuinely included in the ZIP, not just their names. On the other hand, only what your selection actually references is carried over — nothing unused, and nothing belonging to an unchecked module.

Checking a module automatically checks its start graph and cascades to everything wired into it: variables, sub-graphs opened from a block, files in use. Checking a standalone graph (outside any module) works the other way: if it belongs to a module, that module gets checked along with it.

📥 Importing an Exported Module

In the same window, on the destination project, click Import and pick the ZIP file. The import:

1. creates a new file folder named Import-<file name> in your file library, so imported assets don't mix with the ones already there;
2. drops every binary file from the ZIP into it;
3. recreates the resources (graphs, blocks), variables and modules with the same internal ids they had at export time.

A success message confirms once the operation is done.

💥 Name Collision: the Silent Trap

🔺 If the destination project already has a module with the exact same name as the one you're importing, that specific module is not imported — it is simply skipped. No error is shown for this specific case: the success message still appears, as if everything went fine, even though one or more modules from your selection were silently dropped.

What to do: before importing, check that no module in the destination project already carries the exact name of one you're importing — rename one of the two beforehand if needed. After importing, count the modules you got to confirm they're all there.

Two rarer cases worth knowing about:

• If an imported resource already shares the same internal id as an existing one (typical case: re-importing the same file twice), the imported version silently replaces the existing one.
• Variables, on the other hand, are never deduplicated: re-importing the same file twice can create duplicates.

→ Next step: before an export meant to be re-imported elsewhere, rename your modules so they don't carry a generic name ("Module 1", "New module"…), which multiplies the risk of a silent collision on arrival.

Updated on: 21/09/2026