Testver Cloud

Introduction

What is Testver Cloud?

Testver Cloud is Testver running for you, on a server we look after, instead of on your laptop. You get your own private machine at your own address — your-name.cloud.testver.com — with the full Testver application on it, awake and reachable at any hour from any device.

It is the same Testver you already use. Same screens, same features, same project. What changes is where it lives.

Note

In one sentence: your Testver, at your own URL, running whether or not your laptop is open — with backups, self-repair and every test framework already installed.

Who this is for

• Anyone whose schedules never run because the machine that was supposed to run them was asleep.
• Teams who want one shared environment rather than “it works on my setup”.
• People who switch machines — a laptop, a desktop, a borrowed machine — and want the same Testver on all of them.
• Anyone tired of environment setup — the right Node, the right JDK, the right Python, browsers that actually launch.

Availability

Testver Cloud is included with the Power and Team plans and is self-service from your dashboard: open Cloud, and if your plan includes it the page offers to create your workspace. The plan also sets the machine size you get. If your plan does not include it, the page says so — upgrade, or ask your Testver administrator, who can grant it to an individual account.

Every plan comes with exactly one workspace. For a team, that workspace belongs to the team and is shared by everyone in it; the team owner, and one member the owner names platform manager on the Team page, are the people who can create, restart, repair and reconfigure it. Other members use the workspace and see its status, but do not manage it.

Advantages

It is always awake. Schedules fire at 3 a.m. whether or not anyone is logged in. A nightly regression run does not depend on someone remembering to leave a machine on.

Every toolchain is already there. A workspace ships with Node, Python, Java (three LTS versions), .NET, Ruby, Maven, Gradle — and, critically, browsers that actually launch: Chrome and Firefox with the system libraries they need. No “works on my machine”, no afternoon lost to a broken driver.

Your dependencies install themselves. Connect a repository and Testver Cloud works out what it needs — npm ci, a Python virtual environment, a Maven build, a Ruby bundle — and installs it. You do not run the setup command; the workspace does.

It repairs itself. If the Testver process stops, it restarts within seconds. If the machine itself becomes unhealthy, it is replaced with a new one and your work is restored onto it automatically, dependencies included. In the ordinary case you find out it happened by reading the status, not by losing a morning.

Your work is backed up continuously. Your project, your uncommitted edits and your Testver settings are archived roughly every half hour to storage in a different company from the one running your machine. You can restore an earlier archive yourself, or download everything at any time.

Reachable from anywhere. A browser is the only requirement. Your address is served over HTTPS with a certificate that renews itself.

It is genuinely yours. One machine per customer — not a shared server with other people’s projects on it. Your repository token lives on your machine only, and is never stored in our database.

How to use it

1. Get a workspace

Open Cloud in your Testver account dashboard and press Create my workspace. You choose a name — this becomes your address, your-name.cloud.testver.com (a team’s defaults to the team name) — and set the password you will sign in to Testver with. Nothing is reserved until you actually create it.

Provisioning takes about a minute. When it finishes, the workspace is ready and the address works. On a team, only the owner or the platform manager can do this step.

2. Connect your repository

1. Open Cloud in your Testver account dashboard.
2. In Repository, paste the HTTPS URL of your repo and an access token.
3. Press Connect.

Testver Cloud clones the repository onto your workspace and then installs whatever it declares. Watch the Dependencies card: it shows the stack it detected, the exact command it ran, and whether it succeeded.

Note

Your repository token is written only to your own workspace machine, and is used for pulls and pushes from there. It is never kept in the Testver database.

3. Work

Open your address, sign in, and use Testver exactly as you do locally — Test Explorer, the Runner, AI Assistant, schedules, all of it.

Two things are worth setting up early:

• Schedules, because this is where they finally make sense — nothing has to be left switched on.
• Testver Grid as the execution target, so browsers run on the grid rather than competing with Testver for your workspace’s memory.

4. Look after it (briefly)

The Cloud page in your dashboard is the whole administrative surface:

Card	What it is for
Health	Whether your workspace is serving normally
Restart server	A safe restart of the Testver process, about ten seconds
Dependencies	The detected stack, the install command, when it last ran, and a Re-run setup button
Repository	Connect or change the repo, and the branch
Backups	Every archive, with Restore — and Download my data for a copy of everything

Most weeks you will not open this page at all.

What happens when something goes wrong

You do not have to do anything, and it is worth knowing what the system is doing on your behalf:

1. The Testver process stops. It restarts in about three seconds. You may not notice.
2. The machine stops responding. It is rebooted.
3. The machine cannot be recovered. A new one is built from a clean image, your most recent archive is restored onto it, and your dependencies are reinstalled. Your address does not change, and you keep working at it.

The one thing worth knowing: your project files, uncommitted edits and settings are all in the archive. Reinstallable material — node_modules, a Python virtual environment, downloaded browsers — is deliberately not, because it is rebuilt for you rather than stored.

Ending a workspace

If you stop, your final backup is kept for a defined window so you can still download it, and you are told the date. Nothing is deleted the moment you leave.

You can take a full copy of your data at any time, whether you are leaving or not — Download my data on the Cloud page. On a team, ending the workspace and downloading its data are reserved for the team owner; the platform manager can do everything else.

FAQ

Is this the same Testver I use now? Yes — the same application, the same version, the same screens. Only the location changes.

Do I still need Testver on my laptop? No, but nothing stops you. Some people keep a local install for offline work and use the cloud workspace for scheduled and shared runs.

What is actually installed on the machine? Node, Python, Java 17/21/25, .NET, Ruby, Maven, Gradle, plus Chrome, Firefox and the system libraries browsers need. Your project’s own dependencies are installed from what your repository declares.

Can my whole team share one workspace? Yes — that is how a team plan works. The team has exactly one workspace, everyone on the team signs in to it with the workspace’s own login, and the owner plus one platform manager look after it. Team members do not get personal workspaces on top; for genuinely separate environments, use separate accounts.

How much of my work could I lose? At most about half an hour — that is the backup interval. Connected repositories narrow it further, since anything you have pushed is also in Git.

Where is my data kept? Your machine runs in Germany. Backups are stored with a separate provider, and a second copy is kept with a third one, so no single company holds the only copy of your work.

Can I install extra system software myself? Not directly — workspaces deliberately do not give out administrator rights, which is part of what keeps them safe to run and easy to repair. Anything you can install into your own home directory (a different Node or Python version, additional browsers) works normally. If you need a system package that is missing, ask: it gets added to the image for everyone.

What about my repository token? Stored on your workspace machine only, at rest, used for Git operations from there. It is not in our database, and it survives a repair because it is part of your archive.

Can I run mobile or device tests on it? No. A cloud workspace has no phones attached and cannot run an Android emulator. Mobile testing continues to use a device cloud — see the mobile guides.

Does it run tests, or just host Testver? Both, but think about where browsers should run. The workspace is sized for Testver plus light execution; for anything parallel, point runs at Testver Grid and let the browsers live there.

What is the difference between Testver Cloud and Testver Grid? Testver Grid runs browsers for tests you launch from anywhere. Testver Cloud runs Testver itself, always on. Grid answers “where does the browser run”; Cloud answers “where does Testver run”. They work well together and neither requires the other.

Related

• Testver Grid — cloud browsers for your test runs
• Schedules — the feature that benefits most from an always-on workspace
• Git — working with your repository inside Testver
• Installation — the local install, if you would rather run Testver yourself