Publishing

Publishing turns an authored project into a versioned product people can use. Save the project revision, build and validate its selected targets, then package the downloads and submit the release with its presets, assets and documentation.

In the Help Center: Publishing plugins for preparing a listing and release decisions.

The words

Maru uses the same few words on the command line, in Studio and on the website.

Word	Meaning
publish	Put a new version online under your name. maru publish works out what the folder holds (a module, a sampler bank) and runs that kind's own process.
release	One published version: numbered, unchangeable, installed as @handle/slug@version. A noun, never a verb. Publishing changed files makes the next release number; publishing unchanged files does nothing and says so. You never bump a number by hand.
unpublish	Take a publication offline; its page and downloads stop answering until you publish again. maru unpublish handles sampler banks; archive a module from its project on maruaudio.com.
build	Produce the browser or plug-in files, on your computer or on the server for a release.
visibility	Who can find it: public, or unlisted (reachable by link only).
source access	Who can read the source a release was published with: only you, purchasers, or anyone who can open the page.

Older guides say "deploy"; it means publish. maru module deploy still runs, but maru publish takes every option it had.

Prepare the product

Keep the module declaration, DSP, interface, presets, demo inputs and runtime assets together. Add a clear name, description, artwork, category and usage instructions. Record the rights and attribution for code, recordings, samples, models and other dependencies. Use the current licensing guidance for access and commercial terms.

A good demo explains the musical purpose. Give listeners a useful starting preset and a representative input; do not rely on undocumented processing to make the preview sound finished.

Save, validate, build, review

Save a durable source revision before requesting a release. Validate audio health, control behavior, state/preset restoration and assets. Build only the targets the module and host support, then test the actual artifacts. In a local project, maru module check runs these checks (add maru module eval for a Graph module), and maru module pack prepares a versioned Release without uploading it. maru publish --dry-run shows the upload without signing in; after maru login, maru publish uploads the module to your profile and prints its @handle/slug@version reference. See Check, build and export. A browser preview, generated package and verified native plugin are different milestones. See Check, build and export, Native plugins and audio consistency.

Web-only projects retain that scope until their runtime is qualified for another target. Available formats and download links should come from the actual release, not a blanket platform promise.

For platform builds, installers and download delivery, follow Package and release audio plug-ins.

Updates and shared content

To automate a local project, follow Build and publish a module in CI. It shows build downloads first, then optional publication on stable GitHub releases, with the required toolkit and credential setup.

Preserve module identity and parameter/state compatibility. Review migrations when parameter meaning, range or asset dependencies change. Shared presets need the correct module/schema and assets to remain useful; version a preset or bank alongside the content it depends on.

Keep released artifacts and their source identity traceable. Review rollback, withdrawal and existing-session behavior before replacing a release. Current availability and support should be stated on its product page.

Continue with Studio workflow, Project structure or the engine.