Codespaces Free Tier
You use the codespaces free tier by opening a cloud workspace from your personal account. GitHub gives every personal user monthly compute hours and storage space at no cost. Many teams start by testing code in these free cloud spaces. Problems start when devs store broad keys or wide roles inside those remote spaces. If an account gets compromised, an attacker can use those stored keys right away. How the codespaces free tier works A cloud workspace runs inside a virtual machine hosted by th
Free Tier: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You use the codespaces free tier by opening a cloud workspace from your personal account. GitHub gives every personal user monthly compute hours and storage space at no cost. Many teams start by testing code in these free cloud spaces. Problems start when devs store broad keys or wide roles inside those remote spaces. If an account gets compromised, an attacker can use those stored keys right away.
How the codespaces free tier works
A cloud workspace runs inside a virtual machine hosted by the platform. When you open a repo in the cloud, the system starts a container. That container loads your code, your tools, and your runtime settings from a file. The codespaces free tier tracks two main things each month: active compute time and disk storage.
Compute usage counts up while your cloud workspace is active and running. The size of the machine changes how fast you burn through your free hours. A bigger machine with more cores uses your monthly quota much faster. When you stop working, the system pauses the machine after a set idle time. Once the machine stops, the compute clock stops ticking too.
Storage usage works in a different way. Your workspace saves files, packages, and container data on a virtual disk. That disk keeps using your storage quota even when the machine is stopped. The only way to free up that storage space is to delete the workspace. At the end of the billing cycle, your free usage counters reset to zero. If you hit your limit early and keep spending limit at zero, your workspace stops until next month.
Managing secrets and roles in cloud workspaces
Devs need a way to talk to test databases and internal systems from the cloud. Most platforms let you save user secrets or repo secrets in your settings. When the workspace boots up, the platform puts those secrets into the shell. This makes it easy for your app to run tests and read remote data.
This native setup solves the basic problem of getting a workspace running fast. It checks who owns the account and controls who can boot the virtual machine. It also keeps secrets out of your source code files.
Free Tier: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Yet this setup leaves a big gap during daily work. Once a secret loads into the shell, any script or tool in that workspace can read it. A single bad package can steal that database key and send it out. Also, repo roles only decide who can start the cloud machine. They do not check what commands or queries a dev runs inside a database session. If a dev runs a broad delete query, the workspace will not stop it. And if a query pulls back user emails or card numbers, raw values show up in the terminal.
Keeping usage low and security tight
You can stretch your free quota by changing a few simple habits. Pick the smallest machine size that still runs your build tools well. Stop your workspace right when you finish a task instead of waiting for the timeout. Delete old workspaces from past branches so they do not eat up your disk quota. You can also set a rule to delete stopped workspaces after a few days.
For security, never paste raw production keys into a cloud workspace file. Give test workspaces narrow database roles that can only read sample tables. Keep production data out of free personal spaces whenever you can. When devs must touch real systems from remote spaces, control each command at the database level.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
Does a stopped workspace still use my free monthly quota?
A stopped workspace does not use any of your monthly compute hours. Still, its saved files still count toward your monthly storage limit until you delete it.
What happens when I run out of free hours for the month?
If your spending limit is set to zero, your running workspace will stop working. You must wait for the next billing cycle or add a payment method to keep working.
Can team accounts use the personal free quota for shared repos?
The free quota applies to personal accounts rather than paid team billing plans. Check your billing settings to see who pays for workspaces started on a shared repo.