Namespace delivers unparalleled speed and security for Docker builds, empowering you to ship your applications faster and with confidence.
Namespace Remote Builders are remote, fully-isolated microVMs optimized for building Docker images. They ship with 16+ CPU cores and 32+ GB of RAM, Buildkit installed, and a persistent cache. We also offer an isolated Container Registry. You can pull the Docker images locally or push them to an external registry or Namespace Container Registry.
You may think of Remote Builders as Build-as-a-Service (BaaS). We manage the entire infrastructure and orchestration of these builder instances for you. So you can focus on the actual development of your application. Faster builds also allow you to iterate more quickly over your product, letting you discover and fix bugs on time.
On top of the additional compute resources, our Remote Builders persist across subsequent build runs of your Workspace, so we maximize the cache hits of your builds and those of your team. As a result, you'll see more effective caching and near-instantaneous build times!
We take security very seriously at Namespace Labs. Our Builder instances are private to each Workspace and run with total isolation. Our infrastructure also monitors and enforces resource usage for every user, preventing noisy neighbors from slowing your builds down.
We host Intel and Arm machines, so you can build your applications for both platforms on native architectures without going through slow hardware emulation.
When to use Namespace Remote Builders
We optimized our Builder instances for things that matter the most for teams of developers.
Speed up Docker builds: Remote Builders are the perfect solution for developers tired of slow Docker builds caused by limited compute resources on their laptops or Continuous Integration platforms. With at least 16+ CPU cores and 32+ GB of RAM, our Builders provide the necessary computing power to speed up your builds.
Share Docker images across your team: Docker builds and container registries typically live in different places. For example, the image gets built in a developer's laptop and then pushed to a remote container registry which is inefficient. You can improve the situation by exporting the image to the local Docker daemon. But this makes sharing the image with your team harder. With Namespace Remote Builders, you can have the best of both worlds. Our Namespace Container Registry provides the performance and collaboration capabilities to efficiently share your images with your coworkers.
Share builds cache within your team: Builder instances are persisted within the team's Workspace and across builds, which makes the cache store all the build intermediate steps and results. This shared cache avoids expensive, duplicate work of rebuilding existing images.
Build Intel and Arm images: Arm machines are becoming increasingly popular these days, and developers need to build their software for both architectures quickly and with zero hassle. In Namespace Labs, we host Intel and Arm machines so that Builder instances can run natively on them, and the Docker builds are not slowed down but hardware emulation.
Troubleshoot build logs: Developer teams often need help with failing Docker builds. The standard logs from Docker or Buildkit are hard to parse and understand, especially when running in traditional CI platforms. With Remote Builders, debugging is much easier. Our Namespace Web UI streams logs and highlights errors from the Remote Builder. This debugging experience saves precious time for the team when they want to fix the build and go back to active development.
Build on Remote Builders
You can issue the
build command through our
nsc CLI to start building. Namespace automatically creates
your Builder instance if it does not already exist, and the Docker build will begin in a few seconds.
Your Workspace hosts a private container registry. The
nsc CLI automatically injects
the Workspace registry when
--name flag is specified.
$ nsc build . --name app --push
The command will issue a build request and stream the Buildkit logs back to you. At the very end, it will print the full name of the image, including tags. For example:
By default, we recommend taking advantage of our Namespace Container Registry for optimal performance. But we also offer the option to push the resulting Docker image to any container registry.
If a coworker issues a similar command, the same Builder instance will process the build request. The Buildkit engine handles concurrent build processes within a single instance.
Push to external Container Registry
We understand you might already have your development workflow consuming Docker images from a specific container registry.
nsc can push to any container registry that exists out there. Authentication is the same as Docker.
See their documentation of docker login.
$ nsc build . -t <registry>/<repository>/app:latest --push
Export to local Docker registry
Sometimes, building the Docker image and having it locally is helpful for quick development increments. Especially for local development, where you want to have fast builds because you need to iterate over the product quickly. You can take advantage of the persisted cache within the Remote Builder.
$ nsc build . --load
After completing the build, the command will print the SHA of the resulting Docker image. For example:
Loaded image ID: sha256:32b7e72106c3088c326dd779877415080510a6a0cfe94d19490d3c91fa7dd845 Took 1.596041125s to upload the image to Docker.
Multi-platform container images
Container images can support multiple platforms, meaning a single image may contain variants for different architectures.
Namespace supports building multi-platform container images. When you invoke a
build, you can set the
--platform flag to specify the target platform(s) for
the build output. For example:
$ nsc build . -n app --platform=linux/amd64,linux/arm64 --push Pushed for linux/arm64: nscr.io/8enum0hp1l5ii/app:linux-amd64-bnhdk6g Pushed for linux/arm64: nscr.io/8enum0hp1l5ii/app:linux-arm64-64r87fg Multi-platform image: nscr.io/8enum0hp1l5ii/app:latest
The command above builds an image for two platforms (
pushes it to the Namespace Container registry.
By default (when the
--platform flag is not specified), Namespace builds an
Namespace will build the image for the local host platform instead when providing the
Note that exporting multi-platform images to the local Docker registry is not supported. The
--load flag only supports single-platform images.
You can access multi-platform images using, for example,
docker CLI. To pull
an image for a specific platform, specify the
--platform CLI flag. For example,
to pull a
$ docker pull nscr.io/8enum0hp1l5ii/app:latest --platform=linux/arm64
By default (when the
--platform flag is not specified), docker CLI pulls images
of the local host platform.
- Make your builds fast with our Remote Builders guide.
- Chat with the team on Discord.