Building Apps

What It Is

An App is a saved workflow compressed into one reusable block. Instead of rebuilding the same chain of Prompt, Image, Video, 3D, or Audio blocks every time, you package the chain once, choose which inputs should stay editable, and then run it from a single App block.

Apps are useful when a workflow has a clear repeatable job:

• product image cleanup
• prompt-to-image systems
• image-to-video pipelines
• multi-step style workflows
• internal team templates
• reusable client delivery flows

Apps are different from the built-in Image Apps inside the Image editor. Image Apps are predefined tools for image operations. App blocks are workflows that you create from your own canvas.

Create an App

The in-app guide follows the same flow shown below. Open it from the canvas Apps menu with Create new App, or select a workflow directly and click Make App.

1. Build the workflow on the canvas

Start with a normal connected workflow. The first version of Apps supports these block types inside the package:

• Prompt
• Prompt Agent
• Image
• Video
• 3D
• Audio

The selected workflow must be one connected chain or directed graph. It cannot contain cycles, and it cannot depend on an upstream block that is outside your selection. Apps can include up to 20 blocks.

2. Select the workflow

Select at least two connected blocks. The selection must include at least one terminal media output block, because the App needs something concrete to emit when it runs.

After selecting the workflow, click Make App in the selection toolbar.

3. Name and describe the App

In App Creator, add:

• App name - shown in the App picker and on App blocks.
• Description - explains what the App does.
• Category - used for organization and Community publication.
• Thumbnail - choose an image or video from the selected workflow, or upload one.

The thumbnail and description are especially important if the App will be submitted to Community later.

4. Choose dynamic and fixed inputs

Input bindings decide what another user or future run can change.

Dynamic inputs appear as connection inputs on the App block. Use Dynamic for anything that should be provided each time the App runs, such as a prompt, product image, source video, or audio file.

Fixed inputs stay inside the packaged App as defaults. Use Fixed for instructions, references, or setup blocks that should not change between runs.

Every saved App needs at least one dynamic input. Add clear input descriptions so the App block explains what each input expects.

5. Choose exposed outputs

Output bindings decide which generated blocks appear after the App runs. Terminal outputs are selected by default. You can also expose intermediate generated steps if they are useful as results.

Hidden outputs still run if the workflow needs them, but they are not emitted as final result blocks.

6. Choose dynamic controls

Dynamic controls decide which model settings appear in the App settings panel when the App is used.

Use dynamic controls for settings another user may need to change at run time, such as aspect ratio, duration, quality, or other model parameters. Controls left fixed use the saved defaults from the original workflow.

7. Save the App

Use Save draft when you are still configuring the package. Drafts are stored but are not ready to use from the App picker.

Use Save App when the package is ready. Ready Apps appear in My Apps and can be placed on the canvas as App blocks.

Use an App Privately

Apps are private by default. A private App belongs to you, appears in My Apps, and is not visible in Community.

You can add a private App to the canvas in a few ways:

• Open the Apps library from the left toolbar, go to My Apps, and click Add to canvas.
• Right-click the canvas, choose App, then pick a saved App.

When you run an App block, it uses connected dynamic inputs plus the fixed defaults saved inside the package. The run creates temporary internal runtime blocks, executes the packaged workflow, then drops the exposed result blocks beside the App block.

Private Apps are best for personal systems, team workflows, and reusable client templates that are not ready for public distribution.

Submit for Community Publication

Publication is how a private App becomes available in the Community library.

Only ready Apps can be submitted. Imported Community Apps cannot be edited or republished.

To submit an App:

1. Open the Apps library.
2. Go to My Apps.
3. Open the App details.
4. Click Submit for review.
5. Confirm the submission.

Submitting creates a review request for the current version of the App. Your private App stays in My Apps. If the App is accepted, other users can view it in Community and import a copy to their own workspace.

Publication does not make your source project public. The published App is a reviewed snapshot of the accepted App version.

Publication Statuses

Private

The App is only available to you in My Apps. This is the default state.

Pending Review

The App has been submitted and is waiting for review. If you submit a different version, older pending requests can be superseded.

Publishing

The App has been accepted and is being prepared for Community distribution.

Public

The App is accepted and visible in Community. Other users can import a private copy.

Needs Review

The App was public, but its private source definition changed. Submit an update if you want the Community version to use the new version.

Rejected

The App was reviewed and not accepted. Review notes may explain what needs to change. You can update the private App and resubmit.

Publishing Failed

The App was accepted but something failed while preparing the public version. You can resubmit after the issue is resolved.

Updating a Published App

Editing your private App does not automatically change the Community version. This keeps published Apps stable for users who already discovered or imported them.

After changing a published App, submit the updated version for review. If accepted, the Community listing points to the new accepted snapshot.

Imported Community Apps

When you add a Community App, Raelume imports a private copy into your workspace and adds it to the canvas. Imported Apps can be used like other ready Apps, but they cannot be edited or republished as your own Community submission.

If you want to build on a Community idea, recreate the workflow in your own canvas and package a new App from your own blocks.

Good App Design

Strong Apps usually have:

• one clear purpose
• a descriptive name
• a thumbnail that shows the result or workflow use case
• at least one well-described dynamic input
• fixed defaults for internal setup
• exposed outputs that users actually need
• predictable credit and generation-time estimates

Avoid packaging large experimental canvases. Apps work best when the workflow is focused and repeatable.

Troubleshooting

Make App is unavailable

Save the project first, then select at least two connected blocks.

The selection cannot become an App

Check that the selected blocks are connected, acyclic, supported, and do not depend on upstream blocks outside the selection.

The App cannot be saved

Set at least one input binding to Dynamic and make sure the App has a name.

The App is not visible in My Apps

Only ready Apps appear in the ready App picker. Use Save App, not only Save draft, when you want to place it on the canvas.