Hosted runners

A hosted runner is a runner Sencai starts for one of your CI jobs and removes when that job ends. It has its own Docker daemon, so docker build, docker run and similar commands work in a job, and nothing it creates is visible to another job or to another organization. You do not provision hosted runners: you use them by writing a workflow, and you watch them on the CI / Pipelines page. The time a job runs on one is counted in CI minutes, a monthly allowance that every organization has.

What a job gets

A fresh runner. Every job starts on a runner that did not exist a moment earlier. It takes jobs of your organization only, one job, and is removed afterwards. Nothing is kept for the next job: no files, no Docker images, no layers, no cache.
Its own Docker daemon. Containers a job starts run on the job’s own daemon. docker ps in a job shows that job’s containers and nothing else. Images are pulled again by every job, so allow for the download time. Docker Hub images come through a public mirror; see Docker Hub images.
Secrets of your organization. The repository secrets and variables a workflow reads, and nothing from another organization.
Two values for the registry. SENCAI_CI_TICKET and SENCAI_CI_API are set in the job’s environment so a job can ask for a registry credential; see Push images from CI.
A share of your CI minutes. From the moment a hosted runner takes a job until the job ends, including the time spent pulling images, the job uses CI minutes; see CI minutes.

Labels

A job picks hosted runners with runs-on. Hosted runners answer to these labels:

Label	Job image
`ubuntu-latest`	Ubuntu 24.04
`ubuntu-24.04`	Ubuntu 24.04
`ubuntu-22.04`	Ubuntu 22.04

The job images are full Ubuntu images that include the Docker command-line client, Docker Buildx, Git and Node.js. Use actions/setup-node and similar actions to pin the tool versions your build needs. A job that asks for a label not in this table does not get a hosted runner: it waits in the queue as No matching runner, and the row lists the labels that hosted runners offer. The Settings tab lists them too.

What separates your jobs

Each hosted runner is a container group with limits set by Sencai, not a shared machine:

Own daemon, own runner. The Docker daemon belongs to one runner, and the runner to one job. A job cannot see another job’s containers, images or secrets, because they are not on its daemon.
Confined privileges. A job may run docker run --privileged. The container gets the privileges of a root user inside the runner and nothing on the machine underneath: it cannot open that machine’s devices or files.
A narrow network. A job can reach public web addresses over HTTPS and HTTP (ports 443 and 80), a public DNS service, and Sencai itself (your repositories, your registry and the credential service). It cannot reach private network addresses, other jobs, the machines Sencai runs on, or a cloud provider’s instance metadata address. Connections on other ports, including SSH on port 22, are refused.
Nothing that outlives the job. The runner, its daemon and its storage are deleted when the job ends, times out, fails, is stopped or is idle for too long.

Limits

Limits protect other organizations and the platform, and they differ between environments. The Settings tab shows the ones in force for you.

Limit	What it means
Concurrent jobs	How many of your organization’s jobs run at once. The platform sets a maximum; you can set a lower number on the Settings tab, never a higher one
Platform-wide jobs	The whole platform also runs a fixed number of hosted jobs at once, shared by all organizations. Jobs over either limit wait in the queue
Job timeout	A job that runs longer than this is stopped. The default is 60 minutes and the platform maximum is 3 hours; you can set any value from 5 minutes up to the maximum, because pulling the job image alone takes up to two minutes. A timeout your organization saved earlier that is shorter than 5 minutes is read as 5 minutes, and the Settings tab says so
CI minutes	A monthly allowance of hosted job time. A free organization has 30 minutes and cannot go beyond them; a paid organization has more and can use minutes beyond them, which are billed. A job starts only when at least 5 minutes are left. See CI minutes
Memory, processor and disk	A job has a fixed amount of each, shared by the runner and everything the Docker daemon runs. A build that needs more memory than its Docker daemon may use makes that daemon stop and restart, and the job fails (its log typically says “Cannot connect to the Docker daemon”). The job shows Failed on the Hosted runners tab with the reason “the job ran out of memory”, which names the daemon’s memory limit
Start time	A runner that does not come up within about 10 minutes is removed and shows Could not start
Idle time	A runner whose job never arrives is removed after about two minutes and shows No job. That is normal and uses no CI minutes

Waiting is shown, not hidden: a job that is waiting for a slot says why and where it is in the line.

Approval

Hosted runners run only for organizations Sencai has approved. If yours is not approved, jobs that need a hosted runner wait in the queue as Waiting for approval and nothing is started for them. Contact Sencai support to request approval. Your own runners are not affected. While your organization is not approved, a job that one of your runners can take shows Waiting (your runner), because no hosted runner can be started for it.

Only Sencai approves an organization or withdraws its approval. No role in your organization can change it, and there is no setting for it. Turning hosted runners on in the Settings tab does not depend on approval: you can do it before your organization is approved, and its jobs then wait for approval. Once the organization is approved, the jobs that were waiting are handled like any other job, and the limits above apply. Each approval and each withdrawal is recorded in your organization’s audit log, with the note the Sencai administrator entered.

People who can read CI (see Who can do what) see where the organization stands in two places: a notice above the tabs of CI / Pipelines, shown on every tab, and a read-only Approval row on the Settings tab.

Where the organization stands	Notice above the tabs	Approval row
Approved	None	“Approved by Sencai on” the date
Not approved	“Hosted CI is not approved for this organisation yet.” Jobs that need a hosted runner wait, and the notice tells you to contact Sencai support	“Not approved.” Jobs that need a hosted runner wait until Sencai approves the organization
Approval withdrawn	“Sencai withdrew the approval of hosted CI for this organisation on” the date. Jobs that need a hosted runner wait until it is approved again	“Approval withdrawn on” the date. Jobs wait until it is approved again
The page could not tell	“Could not read whether hosted CI is approved for this organisation.” Jobs may wait in the queue	“Unknown (the server did not say).”

Where hosted runners are not available, there is no notice and the row says “Not applicable: hosted CI is not available in this environment.” Where approval is not required, there is no notice either, and the row says “Not required in this environment.”

If Sencai withdraws the approval

A withdrawal stops your organization’s running hosted jobs at once. The runner is removed within a few seconds, the registry credential it held is revoked, and the job’s row on the Hosted runners tab reads Stopped (not approved). The job then shows as failed or cancelled on the Runs tab once the Git host closes it. A stopped job cannot be resumed; run the workflow again once the organization is approved. Jobs that are still waiting stay in the queue as Waiting for approval, and nothing is started for them until the organization is approved again.

CI minutes

Hosted runners are metered in CI minutes. Every organization has an allowance of them for each calendar month. A free organization has a fixed allowance and cannot go beyond it. A paid organization has a larger one and can use minutes beyond it, at a price per minute. Only hosted runners use CI minutes: a job on a runner of your own never does. Approval comes first, and a job that waits for Sencai’s approval uses no minutes.

What counts

A job uses CI minutes from the moment a hosted runner takes it until the job ends:

The whole job counts, setup included. Pulling the job image, starting service containers and preparing actions are part of the job, not only the steps of your workflow. Every job pulls its images again, so a large image costs minutes in every job.
Each job is rounded up to a whole minute, and costs at least one. A job that runs for 61 seconds uses 2 minutes.
Waiting never counts. Neither does time in the queue, the time Sencai needs to start a runner, a runner that waits for a job and gets none, or a runner that could not start.
How a job ends does not matter. A job that succeeds, fails, is cancelled, times out, is stopped by a person, runs out of memory, or is stopped because your organization became inactive or Sencai withdrew the approval uses the minutes it ran. A job that ends because of a fault on Sencai’s side counts too; if that happens, ask Sencai support to credit the minutes.
A job belongs to the month in which its runner was started. A month is the calendar month in Europe/Prague time. A job that ends after midnight on the last day still counts in the month it started in.

A job needs at least 5 minutes to start

A job starts only when your organization has at least 5 CI minutes left this month. The image pull alone can take up to two minutes, so a job started with less would spend its minutes on the pull and be stopped in the middle of setup. Because of this floor, up to 4 minutes of an allowance can stay unused at the end of a month. Sencai may raise the number but never lowers it, and the Minutes tab always states the number in force.

When a job starts it is given a number of minutes: the smaller of your job timeout and the minutes your organization has left. The job is stopped when it has used them, and the Hosted runners tab gives the reason as “Stopped: this month’s CI minutes ran out”. Your job timeout still applies, so a job whose timeout is shorter ends on the timeout instead.

Minutes a running job could still use are reserved while it runs, so that several jobs started together cannot use the same minutes. A job can therefore wait while the Minutes tab still shows minutes left: running jobs hold them. A reservation ends with its job, and only the minutes the job used are counted. A running job keeps the minutes it started with, even if the allowance changes while it runs.

The allowance

Organization	CI minutes each month
Free	30, a hard limit
Paid	1,000 for the organization, plus 200 for each Plus seat, 500 for each Max seat and 1,500 for each Pro seat

Free. 30 minutes. When fewer than 5 are left, no job starts until the month ends, or until the organization is on a paid plan and Sencai has confirmed its payment (see Payment must be confirmed below).
Paid. The 1,000 minutes and the minutes of the seats are prorated, the way the price of seats is (see Seats & personal plans). The 1,000 are counted for the days of the month on which the organization was paid. The minutes of a seat are counted for the days the seat is billed: a seat billed for half the days of a month brings half of its minutes. Every member of a paid organization holds at least a Plus seat, so a paid organization with five members, all on Plus seats, has 1,000 + 5 × 200 = 2,000 minutes for a whole month.
Payment must be confirmed. A paid organization’s minutes apply once Sencai has confirmed its payment. Until then it has the free 30 minutes and no minutes beyond them, and the Minutes tab says so. Contact Sencai support if your organization has paid and the tab still says this.

Beyond the allowance

A free organization cannot use more than its 30 minutes. A paid organization can. A minute beyond its allowance costs 0.016 EUR per minute, VAT excluded, and is billed starting with November 2026; nothing is charged for extra minutes yet. In a month before that, no organization has minutes beyond its allowance, whatever its cap, and its jobs wait when the allowance is used up.

The overage cap limits how many extra minutes a month can hold. Your billing owners set it on the Minutes tab:

The default is 1,000 minutes a month. A billing owner can set any whole number from 0 to 100,000, or go back to the default. There is no unlimited setting.
A cap of 0 means no extra minutes: when the allowance is used up, jobs wait.
Lowering the cap never stops a job that is running. Raising it lets waiting jobs start shortly afterwards.
You are billed for the extra minutes you used, but never for more than the highest cap that was in force at any time during that month. A cap you lower late in the month does not cancel extra minutes you already used under a higher one, and a cap changed after the month ended changes nothing for that month.

Extra minutes are billed once the month is over, as one line on the organization’s invoice for that month. If that month’s invoice is already final by then, they appear on the next invoice instead; they are not lost. Sencai support can credit minutes, for example after a fault on Sencai’s side. A credit lowers the count for the month in which it is made; it does not change a month that was already billed, which Sencai corrects with a credit note on the invoice.

When the minutes run out

Jobs stop starting when fewer than 5 minutes are left under the ceiling: the allowance for a free organization, or the allowance plus the overage cap for a paid one.

A new job waits in the queue as Waiting for CI minutes. Nothing is started for it and it has no place in the line. The sentence on the row says why and when jobs run again: from the 1st of the next month at 00:00 (Europe/Prague) and, for a free organization, as soon as it is on a paid plan and Sencai has confirmed its payment.
A paid organization keeps running past its allowance, up to the overage cap. At the cap, or with a cap of 0, jobs wait in the same way.
The Git host cancels a job that waits more than 24 hours, and a cancelled job does not come back by itself. Run the workflow again after the minutes reset, after the organization is on a paid plan and Sencai has confirmed its payment, or after a billing owner raises the cap.
Jobs that are already running are not affected, except by the minutes they started with (see above).

When the allowance changes during the month

The included minutes on the Minutes tab are a projection to the end of the month. They go up at once when a seat is added or raised to a higher plan, and when Sencai confirms that the organization has paid. They go down when a Plus seat is removed or the organization stops being paid. A Max or Pro seat that is removed keeps counting to the end of the month, as it is billed to then. Minutes used under an earlier, higher projection count against the lower one, and the part above it is billed as extra minutes when the month closes, up to the highest cap that was in force during the month.

An organization that stops being paid during a month has an overage cap of 0 from that moment: its jobs wait as soon as its minutes are used up. Extra minutes it used while it was paid are still billed, up to the highest cap that was in force.

Notices

Your billing owners are told by e-mail and in the platform when:

80 % of the allowance is used.
The allowance is used up. For a free organization, and for any organization with an overage cap of 0, this is when fewer than 5 minutes are left, because that is when jobs stop starting. A paid organization with a cap above 0 is told when it uses up its allowance, because extra minutes start there.
The overage cap is reached, for a paid organization with a cap above 0: fewer than 5 minutes are left under the cap and jobs wait.

Each notice is sent once for each organization, month and channel, and only where Sencai enforces CI minutes.

Docker Hub images

Your job’s Docker daemon pulls images from Docker Hub through mirror.gcr.io, a public mirror of Docker Hub that Google runs. Pulls the mirror serves do not count against Docker Hub’s pull limit, and most workflows need no change for it. In a job, docker info lists the mirror under Registry Mirrors. Only Docker Hub images go through it: images from GHCR, Quay, your organization’s container registry or any other registry come from that registry directly.

When the mirror does not have an image, or does not answer, the daemon pulls the image from Docker Hub itself. Those pulls come from an address that hosted jobs share, and Docker Hub’s limit for anonymous pulls applies to that address. Google does not promise that the mirror is always available or that it holds every image. One case does not switch over to Docker Hub: if the mirror finds a base image for docker build and then fails to deliver it, the build fails. Run the job again.

These pulls do not come from the mirror; they come from Docker Hub directly:

a builder created with the Buildx docker-container driver, which is what docker/setup-buildx-action creates by default;
a Docker daemon you start inside the job, such as docker:dind;
docker manifest inspect and docker buildx imagetools, which ask the registry directly;
an image reference that spells out registry-1.docker.io/. Plain Docker Hub names such as alpine:3.20 or docker.io/library/alpine:3.20 use the mirror;
most pulls of a job that is logged in to Docker Hub; see Private images and your Docker Hub login.

To build through the mirror, use the job’s own daemon: docker build, or docker buildx build without creating a builder of your own. If your workflow uses docker/setup-buildx-action, set driver: docker on it to build with the job’s own daemon, or keep its builder and give that builder the mirror:

- name: Set up Docker Buildx
  uses: docker/setup-buildx-action@v3
  with:
    buildkitd-config-inline: |
      [registry."docker.io"]
        mirrors = ["mirror.gcr.io"]

If you keep a builder or daemon of your own without the mirror, log in to Docker Hub first (below), so its pulls count against your own Docker Hub account.

Private Docker Hub images still work with a login. With a login, pulls that reach Docker Hub count against your own Docker Hub account instead of the shared address. Where you put the login depends on what pulls the image.

The runner pulls the images of container: and services: while it sets up the job, before any step runs, so a login step comes too late for them. Give them credentials: from secrets; a services: entry takes the same block:

container:
  image: your-org/private-image:1.0
  credentials:
    username: ${{ secrets.DOCKERHUB_USER }}
    password: ${{ secrets.DOCKERHUB_TOKEN }}

For the docker commands in your steps (docker pull, docker run, docker build, docker compose), log in to Docker Hub in a step before them. To log in without putting the token on a command line, pass it through the environment and read it from standard input:

- name: Log in to Docker Hub
  env:
    DOCKERHUB_USER: ${{ secrets.DOCKERHUB_USER }}
    DOCKERHUB_TOKEN: ${{ secrets.DOCKERHUB_TOKEN }}
  run: printf '%s' "$DOCKERHUB_TOKEN" | docker login -u "$DOCKERHUB_USER" --password-stdin

The runner also pulls the images of uses: docker:// steps and of Docker container actions itself. For those it uses secrets named DOCKER_USERNAME and DOCKER_PASSWORD as the login, if your organization or repository has secrets with exactly those names.

Most pulls that use your Docker Hub login send it first to the mirror’s token endpoint on mirror.gcr.io. Google runs that endpoint, and also runs the machines that hosted jobs run on. The endpoint refuses the login, and the image is then pulled from Docker Hub with your login, so these pulls do not come from the mirror. A job sends its login there in three ways:

docker login in a step, for docker pull, docker run and docker compose pull (docker build does not send your login to the mirror);
credentials: on container: or services:, for those images;
secrets named DOCKER_USERNAME and DOCKER_PASSWORD, which the runner uses on its own as the login for the container: image when that has no credentials:, for uses: docker:// steps and for Docker container actions. Nothing in the workflow looks like a login, yet these pulls send the two secrets to the mirror’s token endpoint, and an image from another registry can send them to that registry.

Give your Docker Hub secrets other names, as in the snippets above, if you do not want the runner to use them on its own.

The Queue tab

Queue (/gravity/git/ci?tab=queue) lists the jobs of your organization that are waiting for a hosted runner or running on one. Each row shows the job and repository, the labels it asked for (Runs on), its State with a sentence that says what is happening, and since when (Since). A job in a waiting state shows its place in the line (“Position 2 in the line”). Running and starting jobs have a Stop button.

State	What it means
Queued	A runner will be started for this job
Waiting (organisation limit)	Your organization already runs as many jobs as its limit allows. It starts when one of them ends
Waiting (platform capacity)	The platform is running its maximum number of hosted jobs
Waiting (your runner first)	A runner of your own matches; Sencai waits a short while so that runner can take the job before a hosted one is started
Waiting (your runner)	Only a runner of your own can take this job; no hosted runner is started for it
Waiting for approval	Hosted CI is not approved for your organization, or the approval was withdrawn; the sentence on the row says which. Nothing is started for the job, and it has no place in the line. Ask Sencai support to approve your organization, or register a runner of your own. See Approval
Waiting for CI minutes	This month’s CI minutes are used up, or fewer than 5 are left, and a job needs at least 5 to start. Nothing is started for the job and it has no place in the line. The sentence on the row says why and when jobs run again. See CI minutes. A paid organization whose payment Sencai has not confirmed yet has only the free 30 minutes, and the sentence says so
Waiting for other jobs	The job lists other jobs it needs, and they have not finished
Starting	A runner is being started for this job and is pulling its images
Running	A hosted runner is running this job
Stopping	The runner is gone but the Git host has not closed the job yet. This can take a few minutes; the job then shows as failed
No matching runner	No hosted runner offers the labels in `runs-on`
Hosted CI off	Your organization turned hosted runners off and none of your own runners matches
Organisation inactive	The organization is suspended or deleted, or its Git workspace is not ready
Not available	Hosted runners are not switched on in this environment
Start failing	Starting a runner keeps failing. The row shows the last error and when the next try is
Blocked	Sencai has paused starting hosted runners everywhere, for example after one of its own safety checks failed, or because it cannot read which organizations are approved. Nothing in your organization causes it and you cannot clear it; contact support if it lasts
Controller not responding	Sencai cannot currently tell what is happening to hosted jobs. Rows are shown as unknown, never as starting or running

When the allowance is at 80 %, used up or at its cap, a banner above the list says so. If the page cannot trust its own list, it says so in a notice at the top instead of showing an empty table. An empty list under no notice means no job is waiting or running.

The Hosted runners tab

Hosted runners (/gravity/git/ci?tab=runners) is the history of the runners Sencai started for your organization. A row shows the State, the Job (repository, workflow and job), when it Started, how long it Lived, the Minutes the job counted for once it has ended and been recorded, and whether a Registry credential was issued to it (a count, none, or not reported). A job that started with a limited number of minutes shows “Started with N minutes left this month; it stops when they run out”, to people who may see the allowance figures (see Who can see what).

State	What it means
Registering, Starting, Idle	The runner is being prepared or is waiting for its job
Running	The runner is running a job
Stopping	The runner is being removed
Succeeded, Failed	The job finished; the state is what the Git host reports. A job that needed more memory than its Docker daemon may use is Failed with the reason “the job ran out of memory”, which names the daemon’s memory limit; if the reason says instead that the job’s Docker daemon was restarted, memory is the most common cause (see Limits)
Cancelled	The job was cancelled
No job	No job arrived, so the runner was removed. It used no CI minutes
Timed out	The job ran past your timeout, or used all the CI minutes it started with, and was stopped. The reason says which
Runner failed	The runner itself failed, not your workflow. The reason can be “the runner ran past its deadline”, “the node ran out of resources” or “the runner ran out of memory” (the runner process itself, not your build)
Could not start	The runner could not be started
Stopped by a user	A member stopped the job
Stopped (organisation inactive)	The organization was suspended or deleted, or hosted runners were turned off, while the job ran
Stopped (not approved)	Sencai withdrew the approval while the job ran. The job was stopped and its registry credential revoked. See If Sencai withdraws the approval
Lost	Sencai lost track of the runner. Any registry credential it held was revoked

A job stopped because its CI minutes ran out shows the reason “Stopped: this month’s CI minutes ran out”. Its state is usually Timed out, and Failed or Cancelled when the runner stopped it first.

A state this page does not know is shown as “Unknown state” with the raw value, never as success.

Stop a job

Stop on a queue row or a runner row asks for confirmation (Stop this job?, then Stop job). The runner is removed within a few seconds and any registry credential it held is revoked. A stopped job cannot be resumed; run the workflow again to retry. The job then shows as failed or cancelled on the Runs tab once the Git host closes it.

The Minutes tab

Minutes (/gravity/git/ci?tab=minutes) shows the CI minutes of the active organization for this month, or for an earlier month (the selector goes back 12 months). It shows:

A bar of the minutes used against the minutes included, with the extra minutes, the minutes reserved by running jobs and the overage cap marked on it.
A status for the month (for example 80 % used, used up, or at the cap) and when the month resets (“Resets 1 Dec, 00:00 (Europe/Prague)”).
Why the numbers are what they are. For a free organization: a short explanation and a link to upgrade. For a paid organization whose payment Sencai has not confirmed: that its minutes follow the free allowance until then. For a paid organization: how the included minutes are made up (the days it was paid, the 1,000 minutes and the minutes of each seat plan).
The price of an extra minute and whether extra minutes are billed. In a month in which extra minutes are not available yet, the tab says from which month they are.
The overage cap, for people who may change it: an input, an option to use the platform default, and a note that running jobs keep their minutes.
The number of jobs waiting, linking to the Queue tab, and the list of the month’s jobs with Job, Started, Ended, Billed, Minutes and Outcome. Adjustments by Sencai support appear in the same list, shown as “Sencai support”, with the reason support gave. A debit that support adds can hold back new jobs but is never billed; a credit lowers your count.

Where Sencai does not enforce limits, where the page cannot read the figures, or where Sencai cannot currently tell whether limits are enforced, the tab says so and never shows a zero in their place.

Who can see what

The tab is open to everyone who has Read CI. Some of what it shows is billing information, so it needs more:

You see	Needs
The minutes used this month, the status, when the month resets, the waiting jobs, the minutes of each job, and every adjustment Sencai support made, with the reason it gave	Read CI (`git.ci:read`)
The included minutes, the minutes left and reserved, the overage cap, the extra minutes, the minutes a job started with, and the breakdown by seat plan	In a month with paid days: access to billing (`billing.seats:read` or `billing:read`). In a month without any paid day, everyone with Read CI sees the free 30 minutes
The price of an extra minute and what it comes to	`billing:read`
Changing the overage cap	`billing:manage`, which your billing owners hold

Someone without billing access who watches the status change while the used minutes grow can work out roughly how many minutes the organization has included over time. They can never see how many seats of each plan it has.

The Settings tab

Settings (/gravity/git/ci?tab=settings) controls hosted runners for the whole organization. Everyone who can read CI sees it; changing it needs the Manage CI permission. The Approval row is read-only: only Sencai can change it.

Setting	Effect
The checkbox in the Hosted runners group (it asks whether to run your organization’s jobs on hosted runners)	Off means no hosted runner is started for your organization. Turning it off also stops jobs that are running on hosted runners and revokes their registry credentials
Concurrent jobs	Lower than or equal to the platform maximum; empty uses the platform maximum
Job timeout (minutes)	At least 5 minutes, because pulling the job image alone can take two minutes, and at most the platform maximum; empty uses the platform default. A timeout saved earlier that is shorter than 5 minutes shows a note (“The stored timeout (1 min 30 s) is below the minimum; jobs get 5 minutes”) and jobs get 5 minutes; it stays as saved until you save a new value
Let CI jobs push images to this organisation’s registry	Allows jobs to request a registry credential. Turning it off revokes credentials that are open now
Events that may get a registry credential	The default events, or a list you choose; see Push images from CI
Allow pull requests from the same repository	Lets runs triggered by a pull request from the same repository, never from a fork, request a credential
Also allow runs with no Sencai member behind them	For runs started by a deploy key, a mirror sync, or the schedule of a member who left; shown only to people who may choose it
Approval	Read-only. Whether Sencai has approved hosted CI for your organization; see Approval for what it can say

Save settings applies the change, Discard changes puts the form back. If the server refuses a value, the page shows why and keeps what you typed. Every change is recorded in the audit log.

The tab also shows the Push from a workflow step for your registry, with a Copy button.

Who can do what

Permission	Lowest default role	What it allows
Read CI (`git.ci:read`)	Viewer	See the Queue, Hosted runners, Minutes and Settings tabs. The allowance figures of the Minutes tab need billing access too; see Who can see what
Update CI (`git.ci:update`)	Member	Stop a running job
Manage CI (`git.ci:manage`)	Admin	Change the Settings tab. Sencai staff cannot use this permission unless you granted them membership
Access to billing (`billing.seats:read` or `billing:read`)	Member	See the included minutes, the overage cap and the breakdown by seat plan on the Minutes tab. `billing:read` also shows the price of an extra minute
Manage billing (`billing:manage`)	Admin	Change the overage cap on the Minutes tab. Your billing owners hold it

Approving or withdrawing hosted CI for an organization: Sencai only. No role in your organization can change it. The approval notice and the Approval row are shown to people who have Read CI.

See permissions in depth for how roles, custom roles and denies combine. Reading the Runs tab needs the repository read permission, not these.

What changed from shared build capacity

Earlier, jobs of every organization ran on shared build capacity. If you have workflows from that time, check them against this table.

Before	Now
Every organization could use the shared build capacity	Hosted runners run only for organizations Sencai has approved; until then jobs wait (see Approval)
Jobs of all organizations shared one Docker daemon	Every job has its own runner and daemon
Docker images stayed cached between jobs	Nothing is kept; every job pulls its images
`ubuntu-latest` was a plain Node.js image	`ubuntu-latest` is a full Ubuntu image with Docker client, Buildx, Git and Node.js
`docker run --privileged` ran with the privileges of the shared build machine	It still works, confined to the job’s own runner
Network access was broader	Only public HTTPS and HTTP addresses, plus Sencai itself (see What separates your jobs)
One job at a time for everybody	Per-organization and platform-wide limits, with a queue that shows its state
The time jobs ran on shared build capacity was not counted	The time a job runs on a hosted runner is counted in CI minutes: a monthly allowance, with a hard limit for a free organization (see CI minutes)
No registry credential for jobs	A job can request a push credential for your organization’s registry only

Check your workflows

Labels. Make sure every job’s runs-on uses one of the three labels above, or a label of a runner of your own. Others wait as No matching runner.
Caches. Do not rely on anything surviving between jobs, including Docker layers and the cache of caching actions. A job that was fast because of a warm daemon is slower now.
Private networks and SSH. A step that deploys with SSH, or that calls a server on a private address, cannot do that from a hosted runner. Use a runner of your own inside that network, or have the server pull the change instead of the job pushing it.
Docker Hub images. Public images come through a mirror and need no change, unless the job builds with a docker-container builder that has no mirror configured (the default of docker/setup-buildx-action) or is logged in to Docker Hub: then most of its Docker Hub pulls come from Docker Hub directly. Private images, and pulls that fail with toomanyrequests, need a login with your own Docker Hub account; see Docker Hub images.
Stored registry credentials. If you stored a registry credential in repository secrets, delete it and switch to the per-job credential.
CI minutes. Every job pulls its images again, and that time counts. Look at jobs that pull large images or start several containers, and remember that a free organization has 30 minutes a month, which a job needs 5 of to start (see CI minutes).

Jobs that were waiting when hosted runners were switched on are not lost: they were not bound to a runner and are picked up like any new job.

Troubleshooting

What you see	Likely cause	What to do
A job stays Queued for a long time	Capacity: another job of yours or of another organization is running	Look at the state of its neighbours on the Queue tab; the position shows where it is. Raise Concurrent jobs only up to the platform maximum
Jobs stay in Waiting for approval	Hosted CI is not approved for your organization, or Sencai withdrew the approval	Request approval from Sencai support. A job that waits longer than a day is cancelled; run it again after approval
No matching runner	A label in `runs-on` is not offered	Use `ubuntu-latest`, `ubuntu-24.04` or `ubuntu-22.04`, or register a runner of your own with that label
Jobs stay in Waiting for CI minutes	This month’s CI minutes are used up, or fewer than 5 are left	Open the Minutes tab. Jobs run again on the 1st of the next month, when a free organization is on a paid plan and Sencai has confirmed its payment, or, for a paid organization, when a billing owner raises the overage cap. A job that waits longer than a day is cancelled; run it again
A job ends with “Stopped: this month’s CI minutes ran out”	The job started with the minutes the organization had left and used all of them	Run it again when minutes are available; a job needs at least 5 minutes left to start. A billing owner of a paid organization can raise the overage cap
The Minutes tab says the organization is on a paid plan but shows only 30 minutes	Sencai has not confirmed the organization’s payment yet	Contact Sencai support if the organization has paid
A job fails with “Cannot connect to the Docker daemon”, and the reason says it ran out of memory	The build needed more memory than the job’s Docker daemon may use, so the daemon was killed and restarted	Reduce parallelism in the build (for example build one image at a time), or use a runner of your own
A step cannot reach a server	The address is private, or the port is not 80 or 443	Use a runner of your own inside that network
`toomanyrequests` while pulling	The pull went to Docker Hub directly and reached its limit: the mirror did not serve the image, or a `docker-container` builder or a Docker daemon started in the job made the pull. Without a login, that is the anonymous limit of the address hosted jobs share	Log in to Docker Hub first, or pull from your own registry or your organization’s container registry. If the job is already logged in, your Docker Hub account reached its own limit
`docker build` fails with `unexpected status code` and a `mirror.gcr.io` address	The mirror found the base image and then failed to deliver it. This is the one case in which a build does not switch over to Docker Hub	Run the job again
A job ends as Timed out	It ran past the job timeout	Raise Job timeout (minutes) up to the platform maximum, or split the job
Start failing	Sencai could not start a runner several times in a row	Wait for the next try; if it persists, contact support with the job and the time

What’s next

Organization plans - the CI minutes included in the free configuration and in a paid plan, and the price of an extra minute
Seats & personal plans - the seats whose days add minutes to a paid organization
Push images from CI - get a credential for your registry that lasts one job
CI & pipelines - workflow files, the Runs tab, secrets and runners of your own
Container registry - where the images a job pushes end up, and how they are scanned and signed
Permissions in depth - how roles, custom roles and denies combine
Audit log - the record of changes to the settings above, and of each approval and withdrawal
Getting help - how to raise a ticket, for example to ask Sencai to approve your organization