A GitHub Codespace is a development machine running in the cloud, not a CI runner with an editor attached. It stays interactive while a developer edits files, runs commands, starts servers, debugs processes, and commits changes. That distinction explains three behaviors that are easy to confuse: how compute quota is measured, how localhost becomes reachable from a browser, and where CI begins after code is pushed.

Core-hours measure machine capacity multiplied by active time

Codespaces compute usage is measured in core-hours. The accounting model is straightforward:

core-hours = machine cores × active hours

A two-core Codespace running for one hour consumes two core-hours. A four-core machine running for the same hour consumes four. An eight-core machine consumes eight.

This means a quota expressed as core-hours cannot be read as ordinary wall-clock hours without considering the selected machine size. If an account has 120 core-hours available, the theoretical maximum active time is:

2-core machine  -> 60 hours
4-core machine  -> 30 hours
8-core machine  -> 15 hours

The same quota buys less elapsed runtime as the machine becomes larger because the machine can consume more compute capacity at once.

The important word is active. Compute usage starts when a codespace is created or started and stops when the codespace is stopped or deleted. Leaving the editor open is not required for compute to continue. If the codespace is still running, its active time still counts.

GitHub uses an idle timeout to stop inactive codespaces automatically. The default timeout is 30 minutes, and users can configure a different default for newly created codespaces. Reducing the timeout can prevent an abandoned development session from consuming compute longer than necessary.

Storage is accounted for separately. Stopping a codespace ends active compute usage, but its filesystem can remain stored so the development environment can be resumed later.

Codespaces and CI solve different problems

A Codespace and a CI system may run many of the same commands, but their execution models are different.

A developer may run this inside a Codespace:

npm install
npm test
npm run dev

The developer decides when to run the commands, can inspect intermediate state, can edit code after a failure, and may keep the environment alive for hours or days.

A CI workflow typically runs after an event such as a push or pull request:

edit in Codespaces
      |
      v
git commit / git push
      |
      v
CI workflow starts
      |
      +-- install dependencies
      +-- lint
      +-- test
      +-- build
      |
      v
pass or fail

CI is automation around a repository state. Codespaces is an interactive development environment around a developer session.

That boundary matters operationally. A successful npm test inside a Codespace proves that the test passed in that development environment at that moment. A CI run repeats the check in the workflow’s controlled environment and can enforce it for every push or pull request.

npm run dev starts a server inside the remote machine

Suppose a Vite application starts with:

npm run dev

and prints:

Local: http://localhost:5173/

Inside a local development machine, localhost:5173 means port 5173 on that machine. Inside Codespaces, the same address refers to the remote Codespace VM or container, not directly to the browser device.

The process relationship is:

browser on your device
        |
        | HTTPS
        v
GitHub forwarded-port endpoint
        |
        v
Codespace port 5173
        |
        v
Vite dev server

GitHub Codespaces detects localhost URLs printed by applications and can automatically forward the corresponding port. A forwarded port can then be opened from the Ports panel or from the clickable terminal link.

The external address follows a hosted form similar to:

https://CODESPACENAME-5173.app.github.dev

The exact domain should not be hardcoded into application logic because the forwarding domain is infrastructure controlled by GitHub. Codespaces exposes environment variables for cases where a program needs to construct a forwarding-aware address.

Port forwarding is not the same as binding the server

Two network boundaries are involved:

  1. the development server must listen on an address reachable inside the Codespace environment;
  2. GitHub must forward the desired port to the browser-facing endpoint.

Some development servers bind only to loopback by default. If automatic forwarding exists but the application is still unreachable, the server’s bind address is one of the first things to inspect.

For Vite, an explicit bind can be requested with:

npm run dev -- --host 0.0.0.0

or directly:

vite --host 0.0.0.0

0.0.0.0 means the process listens on all IPv4 interfaces available inside its network namespace. It does not by itself make the application public on the internet. Exposure is still controlled by Codespaces port forwarding and the visibility assigned to that forwarded port.

That separation is useful for security. GitHub forwarded ports are private by default. Depending on repository and organization policy, a port can also be made visible to an organization or publicly accessible. A development server should therefore not assume that being reachable through a forwarded URL implies it is intended for public use.

A practical Codespaces development loop

For a Node.js project, the normal loop is compact:

npm install
npm run dev

Then the developer opens the detected port from the Ports panel, edits the code, and lets the development server reload the application. Git operations remain ordinary Git operations:

git status
git add .
git commit -m "Describe the change"
git push

After the push, repository automation such as GitHub Actions can run independently of the Codespace.

The full path is therefore:

source repository
      |
      v
Codespace starts
      |
      +-- editor
      +-- terminal
      +-- npm run dev
      |      |
      |      +-- localhost:5173
      |             |
      |             +-- forwarded URL
      |
      +-- git push
             |
             v
          CI workflow

This model keeps the responsibilities separate. Codespaces supplies an interactive cloud workstation. Core-hours measure how much active compute that workstation consumes. Port forwarding bridges a server running inside the remote environment to the developer’s browser. CI begins when repository events trigger automated checks. Treating those as separate layers makes Codespaces behavior much easier to reason about and troubleshoot.

Software Engineering GitHub Codespaces CI Development Environment