Organize tests with projects and folders

Two structures keep your tests tidy:

• A project is the top-level container. Everything — tests, folders, test sets — lives inside a project.
• A folder is a tree inside one project. Folders can nest as deep as you want.

A test lives in exactly one project, and (optionally) one folder within it. If you want cross-cutting labels that ignore this hierarchy, use tags instead.

Create your first project

A new account starts with no projects — nothing is auto-created, so your first move is to make one.

1. Click the “New project” button (the + near the project picker in the Tests explorer).

2. Give it a name (required, up to 100 characters) and an optional description. A name is unique within the organization, whatever its case — “Web” and “web” cannot sit side by side — so the same name can still be used in another organization you belong to.

3. Save. The new project becomes your active project right away.

Switch between projects with the picker dropdown at the top of the explorer. One project is always active, and the list shows its tests and nothing else. Which one is active:

1. The link — the address carries ?project=…, so a link you share opens the same project, and Back and Forward move between projects. A link to one test opens that test’s project.
2. The one you last used in this organization — each organization remembers its own, in this browser, until you sign out.
3. The first in the list, otherwise.

A link naming a project this organization does not have — someone else’s, or one that was deleted — quietly falls back to the next of these. With no projects at all, the explorer offers to create one instead of a list.

Folders

Folders organize tests within the active project. Use the New folder button to create one at the root, or add a subfolder from a folder’s own menu — there’s no nesting limit, so mirror however your app is structured.

Rename or delete a folder from its ⋯ menu (or right-click it), or from the Folder Properties panel on a wide screen. To move a folder, drag it onto another folder (or onto the “move to root” zone) in the tree.

Move a test into a folder

Drag the test onto a folder in the explorer tree. Dropping it on the project (or the root zone) takes it out of any folder. Select several tests first to move them as a group.

Move a test to another project

Open the test’s ⋯ menu in the explorer (or right-click it), choose Move to project…, and pick the project. The test moves one at a time; dragging only moves it between folders of the project it is in.

The test leaves its folder — folders belong to a project — and lands at the top of the destination project; drag it into a folder there if you want one. From its next run on, it runs with the destination project’s environments: its allowed hosts, its signed-in session and its variables. A step that calls a saved API request by name needs that request in the destination project too.

Deleting a project — read this first

A test always belongs to a project, so deleting one asks what happens to what is in it. Only an owner or admin can delete a project.

The danger zone in the project’s settings first shows what the project holds — how many tests and test sets — and then you choose:

• Move them to another project. The tests and the test sets land at the top level of the project you pick. The folder tree belongs to the project being deleted, so it goes; so do its environments, variables and API requests — a moved test that relies on one needs it set up in its new project before it runs.
• Delete them with the project. The tests go with their steps and visual baselines; past run reports stay. A schedule that ran only the deleted sets is turned off, not deleted.

Either way you type the project name to confirm. If someone adds or removes a test while you are deciding, the delete is refused and you are shown the new counts — nothing goes that you did not see.

Deleting a folder (rather than the whole project) works differently: subfolders are removed, and the tests inside them stay in the project, folder-less.

Note

There’s no “you must keep at least one project” rule — you can delete your last project (its contents go with it, since there is nowhere to move them) and land back on the empty state, ready to create a fresh one.

Projects and your team

Projects belong to your organization, not to you personally. In a solo workspace that’s just you. In a team org, who can see and change a project depends on each member’s role — see Organization roles and permissions.

Restrict where a project’s tests may navigate

A test drives a real browser, and a click or a redirect can carry it to a host its author never intended — a production checkout, a third-party site, a tracking domain. Allowed navigate hosts names the hosts a test may open. Leave it empty (the default) and tests go anywhere. The list belongs to an environment: the field in the Environment section of Project settings edits the project’s default environment, says which, and saves with its own button; any other environment’s list is changed through the API or a coding agent (update_environment).

One host per line:

Rule	Matches
example.com	exactly that host, on any port
*.example.com	every subdomain (app.example.com, a.b.example.com), not example.com itself
staging.example.com:8443	that host on that port only
127.0.0.1, [::1]:3000	an IP address, exactly

Matching is case-insensitive and looks at the host of every top-level page navigation — the navigate step, a click on a link, a popup, a form submission. Images, scripts and API calls the page makes are not restricted; the list is about where the test goes, not what a page may load.

A step that would open a host outside the list fails and names the host:

Navigation to 'checkout.example.com' refused: it is not in this project's
allowed navigate hosts (staging.example.com, *.dev.example.com). Add it in
project settings, or clear the list to allow any host.

A direct navigation, a click and a popup are refused before any request is sent; the browser shows a “Navigation refused” page and the step’s screenshot says why. A redirect is the one case the browser follows before Marriska can stop it: the step still fails and the message names the host and the page that redirected there, but that host has received one request. If a flow must never touch a host even through a redirect, keep that host unreachable from the test environment rather than relying on this list.

An environment that names its hosts can also carry a signed-in session for its tests — the session is only ever sent to hosts on that environment’s list.

The same rules apply on a local agent run, and a coding agent can set or change them through MCP: create_project sets the default environment’s list, update_environment changes any environment’s.

Limits

Projects, folders, and test sets are all unlimited on every plan. The only structural caps are inside a single test (variables and data rows) — see Plan tier limits.

Related

• Organize and run tests with tags — cross-project labels
• Test sets — runnable groups within a project
• Organization roles and permissions — who can edit what in a team