A GitHub Codespace is a full development environment running on a cloud VM, tied to a specific repository and configured by a devcontainer.json file, that you reach through a browser or your local editor instead of building the environment yourself.
“Git codespace” usually means GitHub Codespaces specifically, and the confusion worth clearing up early is what it actually replaces. It’s not hosting. It’s the machine you develop on, spun up on demand instead of sitting on your desk.
Table of contents
- What a Codespace actually is
- devcontainer.json: the file that defines the environment
- Machine types and what they cost you in quota
- The free quota for personal accounts
- Port forwarding for previewing your app
- Prebuilds and the idle timeout
- Where a Codespace stops and hosting starts
- How this fits the rest of the stack
- FAQ
What a Codespace actually is
When you open a Codespace, GitHub provisions a container on a cloud VM, clones your repository into it, and configures it according to a devcontainer.json file if one exists in the repo. You get a full Linux environment with your code already checked out, reachable through the browser-based VS Code, the desktop app, or the CLI.
The container is disposable and reproducible. Stop it, and the VM goes away; the filesystem state persists for a while depending on retention settings, but the actual compute is not something you’re paying to keep idle indefinitely the way an always-on server would.
That disposability is the actual point, not a limitation. If your local machine breaks, or you’re on a tablet at an airport, or a teammate needs to reproduce a bug on the exact same setup you have, the environment is a configuration file away rather than a multi-hour reinstall.
devcontainer.json: the file that defines the environment
A devcontainer.json in your repository describes the base image, extensions, and setup commands a Codespace should have, so anyone opening the repo gets the same environment instead of a bare VM they have to configure by hand.
{
"name": "runxbuild-app",
"image": "mcr.microsoft.com/devcontainers/typescript-node:20",
"forwardPorts": [3000],
"postCreateCommand": "npm install",
"customizations": {
"vscode": {
"extensions": ["dbaeumer.vscode-eslint"]
}
}
}This is the piece that makes Codespaces genuinely useful for a team: onboarding a new contributor stops being a wiki page of setup steps and becomes “open the repository.”
The file also travels with the codebase, versioned the same as everything else. Update the base image or add a dependency to postCreateCommand, commit it, and the next person who opens a Codespace gets the updated environment automatically, no separate onboarding doc to keep in sync.
Machine types and what they cost you in quota
You pick a machine size when creating a Codespace, from 2-core up through 32-core options, and the size directly determines how fast you burn through your monthly quota. GitHub bills and measures usage in core-hours, not clock hours.
- A 2-core machine consumes 2 core-hours per real hour of use
- A 4-core machine consumes 4 core-hours per real hour
- An 8-core machine consumes 8 core-hours per real hour
This is the single most common point of confusion in GitHub’s own community forums: someone expects 120 hours of runtime and gets a fraction of that because they picked a bigger machine than they needed.
The fix is boring but effective: default to the smallest machine that comfortably runs your project, and only size up temporarily for something genuinely resource-heavy like a full local build of a large monorepo. Machine size is a per-session choice, not a permanent setting, so nothing stops you from switching back down for regular work.
The free quota for personal accounts
A GitHub Free personal account includes 120 core-hours and 15GB-months of storage each month. On a 2-core machine, that’s about 60 real hours of coding time. GitHub Pro raises that to 180 core-hours and 20GB-months.
Storage bills separately from compute and keeps accruing as long as the Codespace exists, whether it’s running or stopped, until you actually delete it. A stopped Codespace you forgot about is still quietly consuming storage quota every month.
Past the free allowance, usage is billed per core-hour and per GB-month, so an idle Codespace nobody deleted is a real, if small, recurring cost rather than a free parking spot for old work.
Port forwarding for previewing your app
A Codespace can forward a port so you can preview a running dev server from your browser, using a generated URL scoped to your Codespace. This is genuinely useful for sharing a work-in-progress with a teammate or testing on a phone without deploying anywhere.
It is not a substitute for a real deployment. The forwarded URL exists only while the Codespace is running, is not built for production traffic, and disappears the moment you stop the environment.
Forwarded ports can be set to private, visible only to you, or shared publicly with a link, which is the setting people usually reach for when they want a client or teammate to click a URL and see the current state of something. Treat that link as temporary the moment you share it; nobody should bookmark it expecting it to still work next week.
Prebuilds and the idle timeout
Prebuilds let GitHub run your devcontainer’s setup steps ahead of time on a schedule, so opening a Codespace on a large repository doesn’t mean waiting through a full dependency install every time. For big monorepos this is the difference between a two-minute wait and a near-instant one.
By default, an inactive Codespace stops automatically after a period of idle time, which protects you from an accidentally-left-open browser tab burning through your core-hours overnight. You can adjust the timeout, but the default exists for a reason worth keeping in most cases.
Worth checking periodically: the list of Codespaces attached to your account, not just the one you’re currently using. It’s easy to create a new one for a quick fix and forget the last three are still sitting there, stopped but still counting against your storage quota until you actually delete them.
Where a Codespace stops and hosting starts
A Codespace is where you write and run code while you’re building it, not where that code lives once it’s meant for actual users. There’s no persistent public URL meant for production traffic, no real uptime guarantee, and the whole model assumes the environment can disappear when you stop working.
Once the thing you built in a Codespace is ready for other people to use, it needs an actual deployment target: a real host with a build process, a live route, and logs you can check without a running dev session attached.
This is worth stating plainly because the confusion is common enough to have its own recurring thread in GitHub’s community forums: people asking why their Codespace URL stopped working days after they shared it, or why a client can’t reach the app anymore. The answer is always the same. The Codespace was never hosting it in the first place, and nothing about how it was built was meant to change that.
How this fits the rest of the stack
The workflow that actually works: build and iterate in a Codespace where the environment is reproducible and disposable, then deploy the finished service somewhere meant to stay up. RunxBuild deploys straight from a GitHub repository with build logs, a live route, and rollback to a previous deploy, which is the natural next step once a Codespace has done its job. The RunxBuild hosting calculator shows what that next step actually costs.
When the branch is ready to leave the Codespace, connecting the repository on the RunxBuild dashboard gives it a real, always-on home.
Useful related references:
- GitHub Browser Editor: What github.dev Can Do, and When You Need Codespaces Instead
- Replit Alternatives: Separating the Editor from the Place It Deploys To
- Git Workspace: Working Tree, Worktrees, and the Word That Means Three Things
- Deploying from GitHub on RunxBuild
FAQ
How many free hours does GitHub Codespaces include?
A GitHub Free personal account includes 120 core-hours and 15GB-months of storage per month. On the default 2-core machine that works out to roughly 60 hours of real coding time; a bigger machine consumes the quota faster.
What’s the difference between core-hours and clock hours?
Core-hours multiply by machine size: a 2-core machine uses 2 core-hours per real hour, a 4-core machine uses 4. Your actual runtime in a given month depends on both your core-hour allowance and the machine size you picked.
Can I deploy a live website from a Codespace?
Not meaningfully. Port forwarding gives you a temporary preview URL while the Codespace is running, but it disappears when the Codespace stops and isn’t built for production traffic. A finished project needs a real deployment target.
What is a devcontainer.json file for?
It defines the base image, tools, extensions, and setup commands a Codespace should have, so every contributor who opens the repository gets an identical, pre-configured environment instead of a bare container.
Does a stopped Codespace still cost anything?
Storage keeps accruing against your quota as long as the Codespace exists, running or stopped, until you delete it. Compute core-hours only accrue while it’s actually running.