Publishing & frameworks

Build and share a working prototype with one command. After installing the CLI and linking your project with artor init, run this from its folder:

artor publish              # build and ship the next version → latest
artor publish --alias staging   # publish to "staging"; see named-link behavior below

You don’t edit config files, remember build flags, or pick a “deploy type”. Artor works out what kind of app you built and prepares it for preview. Plain artor publish creates a new numbered version; publishing to an existing named link can replace its version in overwrite mode.

One command, any framework

Artor supports both working apps and static pages:

• Live apps can process forms, fetch data, and run other app features.
• Static sites display the pages and assets you publish, including plain HTML prototypes.

TanStack Start needs its Node build output. If publishing can’t find it, give the error to your coding agent to check the build target. Use --entry <path> for a custom location. Plain TanStack Router projects without Start publish as static sites.

Artor supports your project’s package manager, including pnpm; you don’t need to switch it to publish.

Monorepos: publish from the app’s folder

If your repository contains several apps, run Artor from the app you want to publish. Each app folder is linked to its own prototype:

cd apps/web
artor init          # links this folder
artor publish       # builds apps/web and ships its next version

The project link is per-folder, so apps/web and apps/api are two independent prototypes, each with its own versions and links.

A plain HTML folder — no framework, no build

You don’t need a framework at all. If your project is just a hand-written index.html and some assets — no framework, no build script, no build output folder — artor publish ships the folder as a static site as-is, with no build step. Drop in an index.html, run artor publish, and it’s live.

A couple of things to know:

• The homepage must be named index.html and sit at the project root. If there are .html files but none is index.html, publishing stops with a clear message (found .html files but no index.html at the project root. Rename your entry page to index.html) rather than guessing which page is the homepage.
• Artor never packs node_modules, .git, build caches, or secret files into the published bundle, so a stray folder in your project won’t ride along.
• This only kicks in when there’s no framework to detect — adding Next.js or Vite later means that version publishes as the right kind of app automatically, with no flags to remember.

Every publish is a fresh build

Each publish rebuilds your prototype from scratch to use your current code.

If you’ve just built and want to skip the rebuild, add --no-build to reuse what’s already there (it fails clearly if there’s nothing built yet).

Broken builds fail before they go live

Artor checks your prototype before uploading it. If publishing stops:

• Missing homepage: make sure a static site’s main file is named index.html.
• Incomplete build: finish the build, or use --dir to select the correct output folder.
• App cannot start: give the error to your coding agent, fix the problem, and publish again.

If your app needs services or configuration that are only available on Artor, you can use --no-smoke to skip the local startup check. Use this only when you know why the check fails. Your existing versions remain available if a new publish fails before upload.

Artor confirms your link works

After publishing, Artor opens the new link once to check it responds. If you see a warning, open the link yourself and check it. The version is already live; this warning does not undo its publication. See Runtime errors if it cannot start.

Keeping the review widget current

If your project still has @artorapp/web-sdk (the in-page review widget) pinned to "latest", what artor init sets up by default, publish checks whether a newer version is available before it builds. On a normal terminal it asks before updating; with --yes it updates without asking; running unattended with no --yes it skips the check silently, so it never blocks a CI publish. If you’ve pinned an explicit version instead of "latest", publish leaves it alone. Add --no-sdk-update to skip the check entirely.

Reconciling mock data before it ships

If local sample data differs from the version saved in Artor, publishing asks which copy to use. Choose local to keep your files or server to use the saved data.

For unattended publishing, use --mocks=local or --mocks=server when a choice is needed. If Artor cannot check for differences, it also asks you to choose. See Mock datasets for the full workflow.

Useful flags

Most publishes need no flags at all. The ones you might reach for:

--version <name> is still accepted as an older spelling of --alias, but it prints a deprecation notice: everywhere else in the CLI --version means a version number (artor open --version 3). Use --alias.

Honest limits

• A prototype can read any value you give it. Treat previews as staging, and use staging credentials in your environment variables, never production ones.
• Live apps take a moment to wake. The first open after a while may be a little slow while the app starts; it stays warm after that.
• Build limits depend on your plan. The default is 200 MB for static builds on every plan. For live apps, the defaults are 200 MB on Starter, 500 MB on Pro, 1,000 MB on Team, and 1,024 MB on Enterprise. Your organization may have a custom limit.
• Saved source has a separate limit. Its compressed upload can be up to 200 MB. Downloading or remixing also stops if the source files exceed 200 MB after unpacking, even if publishing succeeded. Large videos, datasets, and design exports can make the source too large even when the app itself is small.
• Saved source leaves out dependency folders, build output, and recognized credential files. Check your project before publishing: a password written into an ordinary source file or included in a built page can still be shared. See Getting the source back.

Related

• The publish → review loop — the full round-trip with your team
• Deployments & versions — how version links and aliases work
• CLI reference — every command and flag
• Getting the source back — pull a version’s code or fork it