Cloud workspaces (rolling out)
Turn them on for a project, choose the repository, add secrets, and pick how models are paid for.
A cloud workspace runs one piece of shared work on a cloud machine of its own. It clones the repository, runs the agent with Claude Code, starts the dev server, sends live previews and reports to the team like a Mac. When the run ends, the machine is deleted with everything in it.
Turn them on for a project
Cloud workspaces are off for every project until the team's owner turns them on. On the Mac, the settings are in the project's Team area, under Cloud Runs; the web app has the same controls on the project's pages.
- Turn on Let Editors Run This Project's Work in the Cloud.
- Choose the Repository (see below).
- Add the Team's Anthropic Key, unless your team pays for models with Vix Credits (see Models).
- Optionally add Secrets for the dev server, and set a monthly limit.
Your plan needs to include cloud agents; Pricing lists which plans do.
Start a run
- Open the work's page.
- Under In the Cloud, choose Run in the Cloud.
- Follow it in Live: progress, frames and guidance work as for any run.
- Choose Publish When Ready to have the workspace publish a branch once the result is ready (and approved, when the team reviews this work). Choose Stop to end the run and its machine at once; nothing is published.
A team runs at most 3 cloud runs at once, and a single run lasts at most two hours.
Repository access
The owner picks the repository from those the team's GitHub App installation can reach, and it must be the repository the project is linked to.
- Each run gets a GitHub token for that one repository, valid for about an hour at a time and renewed while the run lasts.
- The workspace pushes only its own
vixentio/branch. It never merges, never force-pushes and never deletes a branch. - Nothing is pushed until someone asks it to publish.
If the GitHub App no longer reaches the repository, the settings say so: install the App for that repository on GitHub again.
Secrets
Some projects need environment variables for their dev server. Editors can add them under Secrets.
- Names follow environment-variable rules, like
STRIPE_TEST_KEY. Values are up to 32 KB, and a project can have 50. - Nobody can read a value back, the person who set it included. To change one, replace it.
- Secrets go only to the processes Vixentio starts, such as the dev server, and never into the agent's environment.
- Use development values only. Never production credentials.
Region
Cloud workspaces run in the United States (US East, Virginia) only, for now. Other regions aren't available yet.
Models: your own key or Vix Credits
The agent in a cloud workspace needs a model. There are two ways to pay for it.
| The team's own Anthropic key | Vix Credits | |
|---|---|---|
| Who bills the model | Anthropic bills your team directly | Your Vixentio plan, in Vix |
| What Vix pay for | The workspace's time and a small fixed cost per run | The model, the workspace's time and a small fixed cost per run |
| Status | Available with cloud workspaces | Rolling out |
Either way, no key ever enters the workspace. With your own key, the workspace's firewall adds it to requests to Anthropic, and nobody can read it back once saved. With Vix Credits, Vixentio's own key stays on Vixentio's server. How runs are charged is in Billing and Vix Credits.
What the workspace can and can't do
- One machine per run. No disk is shared between runs or teams, and the machine is deleted when the run ends.
- Network: only the hosts a run needs are reachable: Vixentio, GitHub for your repository, your package registries and the model provider. Everything else, including cloud metadata addresses and private networks, is blocked.
- Same rules as a Mac: the guard, the permission modes and the list of things never allowed apply unchanged.
- Code leaves the workspace only as the branch it publishes when its starter asks. Teammates see progress, preview frames and the review according to their role.
See the Privacy Policy for exactly what is processed and kept.