Tickets at once

Let a project work on up to four tickets together, each in its own copy of the repository, and what has to be true for that to work.

By default an install works on one ticket at a time. Tickets of one project, and of several projects, wait their turn. Tickets at once lets a project work on up to four tickets together, each one in a copy of the repository of its own, so a slow ticket no longer holds up the ones behind it.

It is safe only where the install can keep the runs apart, so it is never on by default. Where it cannot be safe, it falls back to one at a time and tells you why. Nothing about a run changes while a project runs one ticket at a time.

Standard plans carry one worker today

Each running ticket uses one worker slot of your license, and every standard plan carries one worker. So every project stays at one ticket at a time until Reqursor issues a license with more workers. Tickets at once is not yet sold as a plan feature. If you need it, ask through How to get help.

What you need

All of these have to hold for a project to run more than one ticket at once. The project's Queue page shows the number it really gets and, when that is lower than what you asked for, the sentence that says why.

What	Where you set it	Why it is needed
The project asks for more than one	Tickets at once on the project's Queue page (1 to 4)	The setting itself. The default is 1.
One branch per ticket	Branch strategy in Settings → Projects & repository (the default)	A project that commits every ticket to one working branch has a single line of work and cannot be split.
Isolation that keeps jobs apart	The bare metal Linux install, or the Docker install started with the confinement overlay	Without it one job could read another job's files and processes. See Security.
A worker with more than one slot	The worker slots setting	A slot is one running job. The default is 1.
A license that allows it	The license's worker count	Each running job is one slot.
A run policy that allows it	The run policy, which a plan may only lower	An organization can hold a project at one however its owner configured it.

The number a project gets is the smallest of what it asked for, what its run policy allows and what the install offers (the slots, the license and the isolation together).

Turn it on

Give the worker slots. On Docker, set REQURSOR_DEV_WORKER_SLOTS=2 in .env, then start Compose with the confinement overlay:
```
docker compose -f docker-compose.yml -f docker-compose.confine.yml up -d
```
On a bare metal install, add REQURSOR_DEV_WORKER_SLOTS=2 to /etc/reqursor-dev/reqursor-dev.env, then restart the services:
```
sudo systemctl restart reqursor-dev-web reqursor-dev-worker
```
Open the project's Queue page and raise Tickets at once. A value above 1 is always saved, and the page says what it gets right now.
Run or queue several tickets. Autopilot queues up to the free slots on each tick, in rank order, and each ticket still waits for its dependencies.

What happens while tickets run together

Each ticket has its own copy of the repository, made when the ticket starts and removed when it ends. Nothing a ticket produced is lost: a held change, a cancelled run's work and its ticket branch are saved into the project's own clone first.
Pushes and pull requests are unchanged. They are still made by the product, with the project's credentials handed to that one command only.
Stop works per ticket. Stop ends one ticket and leaves the others running. If the worker stops, running tickets are asked to stop at their next boundary and are queued again.
The live feed names its ticket, so each ticket's page shows its own lines.
Budgets are checked per request, so tickets running together share a project's headroom correctly.
The app a check starts needs its own port. Two tickets must not both start your app on one port. Put {port} in the runtime smoke test's start command, health URL, environment values and teardown command, for example npm start -- --port {port} and http://127.0.0.1:{port}/health, and each run gets a free port of its own. Without it, runs that name the same port take their turn, so a ticket may wait for another's. This also holds for Proof.

What it costs

Memory, CPU and disk. Each running ticket runs your toolchain: a build and a test suite, not only an agent. With four tickets at once, expect about four times the load. Under Docker all running tickets share the runner container's limits, so raise them together with the slots. Each copy of the repository costs its checked out files, not its history.
Model work. Tickets that run at the same time use model work at the same time. The daily and monthly caps still hold, but they are reached sooner. See Budgets and cost control.
The rest of the worker still runs one thing at a time: the license heartbeat, merge tracking, Autopilot, Bug Hunt and the other background work.

When tickets conflict

Two tickets that change the same files will conflict when their pull requests are merged, the same as two people working in parallel. The product does not try to predict that. If one ticket needs another's change, give it a dependency: it then waits until that ticket is merged into the base branch. Tickets that touch different parts of the code run together without trouble.

Why a project may run fewer tickets than it asked for

The Queue page shows the reason in a sentence. The common ones:

Sentence	What to do
This project commits every ticket to one working branch	Switch the project to branch per ticket, or accept one at a time.
This installation runs agent commands without isolation	Use the bare metal Linux install or Docker with the confinement overlay.
The Docker runner does not confine each command to its own job	Start Compose with the confinement overlay and check the runner starts.
Your license allows 1 worker	This is expected on a standard plan. Ask through How to get help if you need more.
The worker runs 1 job at a time	Set the worker slots and restart the worker.
The run policy allows 1 concurrent job	The organization's run policy holds it. Its owner can raise it.

Limits

On Windows the agent runs without the isolation that Linux installs give it, so Tickets at once has no isolation to rely on there and stays at one ticket at a time.
Per-command confinement under the Docker runner has not been verified by Reqursor with real concurrent jobs. Prefer the bare metal Linux install, or start with two slots and watch the first runs.
Tickets that run together need to be independent work. The product keeps the runs apart. It does not decide whether two changes belong together.