Cloud CI: How Hosted Build Services Work and Where They Stop

Cloud CI is continuous integration run as a hosted service: every push starts a fresh virtual machine or container on the provider’s infrastructure, which checks out your code, runs your build and tests, and reports pass or fail back to the commit.

That definition hides the parts that decide your experience: what a runner is, why caching is the difference between a two-minute and a twelve-minute build, how secrets stay out of logs, and where CI ends and deployment begins. This guide covers the mechanics across the main hosted services, and then the question most teams get wrong, which is whether they need a separate deploy pipeline at all.

Table of contents

• What a hosted CI service actually is
• Runners: hosted, self-hosted and what they cost you
• Caching and minutes: where build time and money go
• Secrets and environment variables
• Where CI ends and deployment begins
• A pragmatic setup, and when to add more
• How this fits the rest of the stack
• FAQ

What a hosted CI service actually is

Strip away the branding and every cloud CI system does the same four things. It listens for an event, usually a push or a pull request. It allocates a clean machine, called a runner or agent. It executes a set of steps defined in a file in your repository. And it publishes the result, a green tick or a red cross, as a status on the commit.

The main services differ in packaging more than capability. GitHub Actions is built into GitHub and configured in YAML files under .github/workflows. GitLab CI reads a .gitlab-ci.yml at the root of the repository and is bundled with GitLab. CircleCI and Bitbucket Pipelines are the standalone and Atlassian equivalents. Google’s Cloud Build is a serverless CI/CD platform inside Google Cloud, and the GitLab overview of cloud native continuous integration is a good conceptual read.

Pick the one that lives where your code lives. Moving a repository to get a different CI provider is the wrong end of the problem, and cross-provider setups add tokens, webhooks and failure modes for a marginal feature gain. If the code is on GitHub, start with Actions. If you want a broader survey, our CI/CD pipeline tools comparison lays out the field.

Runners: hosted, self-hosted and what they cost you

A runner is the machine that executes your job. Hosted runners are provided by the service: a fresh Linux VM for each job, discarded when it finishes. That is the default and the reason cloud CI feels effortless. Nothing to patch, nothing left over from the last build, and the job is isolated from every other customer’s.

The limits are the flip side of that convenience. Hosted runners have fixed sizes, so a heavy build that needs lots of memory or a GPU may need a larger tier or your own hardware. Because the machine is fresh each time, anything not cached is downloaded and installed again. And you cannot reach a private network from outside unless you open a route into it.

Self-hosted runners fix all three. You install the provider’s agent on your own server, and the service dispatches jobs to it. You get your hardware, your caches on local disk and access to private resources. You also get all the operational work: patching, cleaning up disks, and the security question of running code from pull requests on a machine inside your network. Treat a self-hosted runner as production infrastructure, because it is.

• Use hosted runners for open source and standard web builds
• Use larger hosted runners when memory or CPU is the bottleneck
• Use self-hosted runners for private network access, special hardware or heavy caching
• Never run untrusted pull request code on a self-hosted runner with network access

Caching and minutes: where build time and money go

Most CI bills are made of repeated work. A Node project that reinstalls all dependencies on every push spends most of its minutes downloading packages it downloaded ten minutes earlier. Caching stores directories such as node_modules, the pip cache or the Docker layer cache between runs, keyed on a lockfile hash so it invalidates only when dependencies change.

name: ci
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npm test
      - run: npm run build

That setup-node cache line is doing the heavy lifting. Our walkthrough of a GitHub Action for npm build goes deeper on that pattern.

Every hosted service meters usage in minutes or a similar credit unit, often with a free allowance and different multipliers for different runner types. I am not quoting allowances, because they change and differ per plan, but the habit is universal: read the meter before you add a matrix of five Node versions and three operating systems, since that multiplies every push by fifteen. Cancel superseded runs, skip CI for docs-only changes with path filters, and run the slow suites only on the main branch or a nightly schedule.

Secrets and environment variables

Your pipeline will need credentials: a package registry token, a cloud provider key, a deploy token. These belong in the service’s encrypted secret store, injected into the job as environment variables at runtime. They do not belong in the repository, in the workflow file or in a Dockerfile, where they end up in an image layer that anyone with pull access can read.

The hosted services mask secret values in logs, but masking is a courtesy, not a safeguard. A command that prints a transformed value, such as a base64 encoding, can leak it, and a debug flag that dumps the environment leaks everything. Keep secrets scoped: per environment where the platform supports it, with the production ones available only to protected branches. GitLab handles variables with protected and masked flags, and we cover the details in GitLab CI environment variables.

Prefer short-lived credentials where you can. Modern providers support OpenID Connect so a job can request a temporary token from your cloud account instead of storing a long-lived key at all. It removes the whole class of problem where a leaked secret stays valid for two years.

Where CI ends and deployment begins

CI proves the change is safe to merge. Continuous delivery ships it. The two are often bolted into one YAML file, which is where many pipelines go wrong: a test job that also holds production credentials, a deploy step that runs from a laptop, or a pipeline so long that nobody waits for it.

The classic pattern is a two-stage flow. CI builds and tests on every push and pull request. On merge to the main branch, a deploy job builds the artifact, pushes it to the host and switches traffic over, ideally with a way back. The deploy job needs the host’s credentials, so it is the job that most deserves protected branches and approvals.

The cheaper pattern, for a lot of teams, is to let the platform own the deploy. If your host connects to the repository, a push to the main branch triggers the build and release on the host’s side, and your CI only needs to run tests. There is nothing to script, no deploy token in the CI secret store and one less pipeline to keep alive. That is git-push deploy, and for a web app or a static site it is often all the delivery pipeline you need.

A pragmatic setup, and when to add more

Start small. One workflow that installs, lints, tests and builds on pull requests. Branch protection that blocks merging on red. Caching turned on from day one. A deploy that happens automatically from the main branch through the host’s own integration. That covers most products until they have multiple services or a compliance requirement.

1. Run tests on every pull request, and require them to pass to merge.
2. Cache dependencies keyed on the lockfile.
3. Keep secrets in the service store, scoped to the branches that need them.
4. Let the host deploy on merge to main, and keep a manual rollback.
5. Only add a custom deploy job when the host cannot do what you need.

Add complexity when it earns its place: matrix builds when you truly support several runtimes, a staging environment when a bad release is expensive, reusable workflows when three repos copy the same file. The teams with the worst pipelines usually built the elaborate version first. Nothing about a deploy needs to be clever, and the fastest pipeline is the one that does the least.

How this fits the rest of the stack

If your CI is really a delivery pipeline in disguise, look at whether the host can take that job. On RunxBuild you connect a GitHub repository and a push triggers the build, with build logs, a live route and rollback to the previous deploy, so CI can stay focused on tests. The setup is in the GitHub deploy docs. To see what the hosting side costs before you rewire anything, the RunxBuild hosting calculator prices a service and its database together, and you can connect a repository from the dashboard.

Useful related references:

• CI/CD pipeline tools compared
• A GitHub Action for npm build
• GitLab CI environment variables
• Deploying from GitHub on RunxBuild

FAQ

What is cloud CI?

Cloud CI is continuous integration delivered as a hosted service. On each push or pull request it starts a clean runner on the provider’s infrastructure, runs your build and tests, and reports the result on the commit, without you operating any build servers.

What is a CI runner?

A runner is the machine or container that executes a CI job. Hosted runners are provided and discarded by the service after each job. Self-hosted runners are agents you install on your own hardware, giving more control and private network access in exchange for maintenance.

How can I make cloud CI builds faster?

Cache dependencies keyed on your lockfile, cancel superseded runs, use path filters to skip irrelevant changes, split slow test suites and run heavy jobs only on the main branch. Dependency installation is usually the largest avoidable cost.

How should I store secrets in CI?

Use the CI service’s encrypted secret store and inject values as environment variables at runtime. Never commit them to the repository or bake them into images. Scope production secrets to protected branches, and prefer short-lived credentials through OpenID Connect where supported.

Is CI the same as CD or git-push deploy?

No. CI verifies changes by building and testing them. CD delivers them to an environment. Git-push deploy is a simple form of CD in which the host builds and releases automatically when you push, so your CI does not need deploy credentials.