Pricing

For Linux, if you run an instance that has 4 vCPU and 8GB RAM for 5 minutes, then that's:

For Windows, running an instance with 2 vCPU and 4GB RAM for 6 minutes is:

For Mac, an instance with 6 vCPU and 14GB RAM running for 3 minutes is:

While we account for a minimum of 1 minute, we always round the next 15 seconds down. For example, 30 seconds of usage is 1 billable minute, 70 seconds is 1 billable minute, and 150 seconds are billed as 3 minutes.

Unit minutes usage per shape can be found under "What is the unit minutes usage and price for each shape?" below.

For Linux and Windows, our standard shapes are multiples of 1 vCPU and 2GB RAM.
For shapes with a different ratio (i.e., 1 vCPU, 4GB RAM), compute units are calculated as:

For example, running a Linux instance on 8 vCPU and 32GB RAM for 2 minutes will be:

Unit minutes usage per shape can be found under "What is the unit minutes usage and price for each shape?" below.

Jobs that run on Windows or macOS consume minutes at a higher rate than jobs on Linux, they consume 2x and 10x the rate respectively.

Below is a breakdown of the cost of each machine shape per platform. Prepaid cost is the effective cost of minutes in your plan, overage is the cost of any usage that exceeds your plan.

We invest heavily in the best infrastructure. Something we care deeply about. We deploy our own hardware across various sites which allows us to offer fantastic performance and price.

Linux and Windows amd64 workflows are running on high-performance AMD EPYC CPUs.

Linux arm64 workloads are running on AmpereOne or on Apple Silicon.

For MacOS, most of your workloads are running on Apple M4 Pro and some on Apple M2 Pro.

Up-to-date usage reports are available in the Dashboard, and are calculated in real time. Check out your current usage here.

To better understand your usage, click on the ‘Explore’ button on the Usage page to break down and filter usage (per platform, shape, GitHub Repository, etc.).

For GitHub jobs, you can check out the Insights page to look at the Duration or Queue time of all GitHub workloads run on Namespace, with breakdowns and filters.

To improve your performance and cost, you can consider:

• Are you using the right shape for your workflows?
  Larger may be faster, smaller may be cheaper if your runner is oversized.
• Are you running on Namespace standard shapes (ratio of 1vCPU : 2GB RAM)?
  This will give you the best price for your usage.
• Are you using cache effectively?

Our support team is here to help you optimize your setup.

You can now run your Windows workflows on Namespace! Windows runners are still in early access while we work on parity for pre-installed software. We're constantly adding more, so let us know if you're missing something. Having said that - some of our early customers report measurably higher performance on Namespace.

For full transparency: Our Windows runners do not yet have support for Cache Volumes or Docker Builders. We expect this to land soon.

To get access, reach out to support@namespace.so

In the table below you will find information on how many vCPUs each devbox shape can boost to.

In the table below you will find information on how many GB RAM are assigned to each devbox shape.

Namespace offers a host of high-performance caching solutions that lead to major speed-ups during test setup and hence lower your usage in terms of unit minutes. Since our caches are backed by high-performance local storage, they are even faster. Our integrated caching solutions (e.g. Bazel, Turborepo) seamlessly integrate with your tooling and provide very high cache hit ratios ensuring consistently fast workflows. Get started.

To use cache volumes effectively, you’ll need to run some workloads for the cache to be filled and widely available. The more regularly you use your cache volumes, the higher the probability of a cache hit and the higher the savings on compute time.

When you attach a cache volume to an instance, we calculate the cost based on two factors: how long your instance was running and the total storage capacity of the cache volume.

This gives us a measurement in GB-hours. For example, if your instance runs for one hour with a 100 GB cache volume attached, you'll be charged for 100 GB-hours.

If you run an instance for 3 hours with a 50 GB cache volume attached, the calculation would be 50 GB × 3 hours = 150 GB-hours.