Skip to contentSkip to Content
Publishing a prototype

Publishing a prototype

Turn the prototype on your machine into a link your team can open and comment on.

Before you start: you need a publisher seat. Then install the CLI, sign in, and check with artor whoami. Not working? See Troubleshooting.

Let your AI do it

Use this prompt in your favorite coding agent and it will guide you through it.

Prompt
Init this folder as an Artor project and publish it to one of my Spaces.

1. Run `artor whoami` to confirm I'm signed in.
   If not, run `artor login`, then STOP and let me approve it in the browser.
2. Run `artor init`.
   When it asks which Space the prototype should live in,
   STOP and let me pick.
   When it asks for a folder, STOP and let me choose an existing one
   or create a new one.
   If it asks for a name, ask me.
3. Run `artor publish` to ship the first version.
4. Run `artor open` and show me the live URL.

Do the steps in order and pause whenever you need my input.

The prompt assumes the CLI is already installed. If artor whoami fails with command not found, the agent should follow Installing the CLI first.

Do it yourself

Open a terminal in the prototype’s folder

Every command below runs from inside the folder that holds your prototype. That’s the folder with the code your coding agent has been working in — the one containing package.json, or index.html for a plain HTML prototype.

If your repository holds several apps, go into the folder of the app you want to publish, not the repository root. Each app folder becomes its own prototype.

artor init

Artor asks a few questions:

  • A name. This is what your team sees in the dashboard. You can rename it later.
  • A Space. Where the prototype lives decides who can open it. Personal keeps it to you until you’re ready; the Organization Space opens it to everyone on the team. See Spaces.
  • A folder. Pick an existing folder in that Space, create a new one, or accept Draft, the default landing spot. See Organizing with folders.

Artor then connects the folder to the new prototype and adds the in-page review widget to your project, so reviewers can comment directly on the running prototype. The widget only shows up on Artor links, never in your local dev server.

You only do this once per folder. From then on, every publish from this folder goes to the same prototype as a new version.

Already have a prototype in Artor and want this folder to publish to it instead of creating a new one? Use artor link with its ID from the dashboard. See the CLI reference.

Publish

artor publish -m "First cut of the onboarding flow"

Artor builds the prototype, checks that it actually starts, uploads it, and prints the live link. A plain HTML folder skips the build and publishes as-is. The note after -m is optional; it becomes the version’s changelog, the short “what changed” your team sees beside it.

You don’t pick a framework or a deploy type. Artor works out what you built (Next.js, Vite, plain HTML, and more) and serves it the right way. See Publishing & frameworks for the full list.

artor open

This opens the new version in your browser. Copy the address bar, or the link printed by artor publish, and paste it wherever your team lives. Teammates with access to its Space can open it and start commenting right away.

The prototype also appears in the dashboard, in the Space and folder you chose. Its ⋯ menu has Move to folder if you change your mind.

Publishing a new version

Made changes after feedback? Run the same command again from the same folder:

artor publish -m "Moved the CTA above the fold"

That creates version 2. Version 1, and every comment left on it, stays exactly as it was. The latest link follows the newest version automatically; each version also has its own numbered link for “please look at this specific build” moments. See Deployments & versions and The publish → review loop.

Where should it live?

artor init files the prototype in a Space and a folder. You don’t have to get it right the first time: you can move a prototype later and its links keep working. Moving it to another Space does change who can open it, and any public links stay live. Still, a little structure up front saves your team from hunting through Draft later.

  • Pick the Space by audience. The Space decides who can open the prototype. Start in Personal if you’re not ready to show it, or in the Organization Space when the whole team should see it. For a client, a squad, or a confidential project, an admin can create a shared Space with its own members (Team plan and above).
  • Pick the folder by project. Folders group related prototypes inside a Space without changing who can see them. Name them after the initiative (“Checkout redesign”, “Q4 onboarding”), not the person. You can create one from the dashboard or the CLI, or let artor init create it for you when you type a new name at the folder prompt.
  • Draft is the catch-all. Anything published without choosing a folder lands in the Space’s Draft folder. Sort it later with Move to folder from the prototype’s ⋯ menu. See Moving between folders.

What to expect

  • The first publish takes the longest. Later publishes reuse unchanged files and are faster.
  • Artor checks your prototype before uploading. If it doesn’t build or doesn’t start, the publish stops there and nothing changes. Paste the error into your coding agent, fix it, and publish again. If you see a warning after the link is printed, the version is already live: open it and check.
  • Live apps take a moment to wake. The first open after a while can be a little slow while the app starts. It stays warm after that.
  • Use demo data and test accounts. A prototype can read any value you give it, so any passwords or keys should be for testing, never for your live product. See Environment variables.

Troubleshooting

artor: command not found The CLI isn’t installed yet, or your terminal hasn’t picked it up. Go through Installing the CLI.

Not logged in. Run `artor login`. Run artor login, approve it in the browser, then publish again.

no build script in package.json You’re probably at the root of a repository that holds several apps. Change into the app’s own folder and run the commands there.

The publish stops with boot smoke test failed Artor couldn’t start the app before uploading it. Give the error to your coding agent, fix the build, and publish again.

It published to the wrong organization If you belong to more than one organization, check which one is active with artor whoami and see Org context.

Installing the CLIThe publish → review loop