Use the hosted product

Your org's worlds, run by Volter: sign the command in, make your app's World on the platform from its folder, and push to it.

This page supplies an executable walkthrough for packages/cli/src/journeys/tutorials.test.ts.

The hosted product runs the same worlds the self-hosted host runs, on Volter's machines. You sign in on the platform with your Volter account, your org holds worlds, and the volter command signs in as you with a personal access token. Everything after that is the same remote add, push and log as a shared world you host yourself.

On the platformCopy Anchor Link

Sign in on the platform and create an org (here, acme). That is all the page needs there: the World itself is made from your app's folder below, with the twins your app uses. Here, where no one is at a browser, a personal access token made under Account signs the command in; the page keeps it in your shell as VOLTER_TOKEN, and the platform's address as VOLTER_PLATFORM.

The appCopy Anchor Link

{ "name": "acme-web", "private": true, "type": "module", "dependencies": { "@octokit/rest": "^21" } }

The app declares the credential it reads. The World issues a throwaway token for its GitHub account, world; that account is separate from the platform org acme. The seed creates world/web through Octokit before any issue is written. It can run again without creating a second repository.

GITHUB_TOKEN=

import { Octokit } from '@octokit/rest';
const github = new Octokit({ auth: process.env.GITHUB_TOKEN });
const { data: { login: owner } } = await github.users.getAuthenticated();
try {
  await github.repos.get({ owner, repo: 'web' });
} catch (error) {
  if (error.status !== 404) throw error;
  await github.repos.createForAuthenticatedUser({ name: 'web' });
}

import { Octokit } from '@octokit/rest';
const octokit = new Octokit({ auth: process.env.GITHUB_TOKEN });
const { data: issue } = await octokit.issues.create({ owner: 'world', repo: 'web', title: process.argv[2] ?? 'Launch checklist' });
console.log(`filed #${issue.number}`);

npm install
npm install -g @volter/world
npm install -D @volter/twin-github

Sign the command inCopy Anchor Link

volter login <platform url> opens the platform in your browser, where you approve the code it shows; here, where no one is at a browser, the token made above signs it in instead. Either way the token is kept in your config directory with the platform's address, and from then on a remote named org/world resolves through it. volter whoami says where the command is signed in, and volter logout revokes its token.

volter login "$VOLTER_PLATFORM" --token "$VOLTER_TOKEN"

signed in
as [email protected]
orgs       acme

Make the org's World from hereCopy Anchor Link

Your app's world is local; its origin is the org's hosted world. volter world init finds the vendors your app uses; remote add makes the org's World on the platform with the same twins (--create; without it, the command asks at a terminal), then asks the platform for its address and a key made for this command, so nothing but your personal token is ever typed. Once the World exists, the same remote add links it on a teammate's machine, and volter world pull brings what was pushed to it into their World. With only one org, remote add origin team --create names it for you. The platform's Create World does the same for a person without a terminal.

volter world init
volter remote add origin acme/team --create

made     acme/team
remote   origin
through

volter open opens the World's dashboard, signed in through the platform.

Write, cut a changeset, pushCopy Anchor Link

The app runs against your local world as always; a changeset gathers what it wrote; push sends it to the hosted world, which answers with a receipt per twin.

volter world up
volter world run -- node file-issue.mjs
volter world changeset -m "The launch checklist"
volter world push

pushed

The World's page (Open, on the platform) shows the changeset in its Changes and Activity. Your teammates clone from the same origin — see Work from a shared world.

volter world down

Keep a World to some of the orgCopy Anchor Link

Every member of an org reaches its Worlds until an admin says otherwise. On the org's Worlds page, Manage access… in a World's menu keeps it to the members you tick; admins always reach it, and the World shows Restricted. A member it leaves out no longer sees it, cannot open it, and gets no key to it; the keys they already held there are revoked when you save, and so are the previews those keys made. Everyone in the org opens it again. An org token acts as the org, so CI keeps working. The same setting is GET and PUT /-/worlds/<org>/<world>/access in the platform API.