Build Context
Many Dockerfiles useCOPY and ADD to include files and directories from the local context into a container. You can get exactly the same behavior when building Blueprints in Runloop by using the object store and build context features.
A build context is useful when you want to:
- Include application source code in your Blueprint
- Bundle multiple files and directories efficiently
- Use Docker’s
COPYandADDinstructions in your Dockerfile
Build contexts are stored as temporary Storage Objects and can be automatically cleaned up by setting a time-to-live (TTL). Make sure to set a TTL that is long enough for your blueprint build to complete.
Example: Creating a Blueprint with Local Application Files
This example shows how to upload a local directory and use it as a build context in your Blueprint’s Dockerfile:If your local directory contains a
.dockerignore file, those patterns will be respected during the upload. This helps reduce the size of your build context by excluding unnecessary files like node_modules or .git.Object Mounts
For larger files, datasets, or binary assets that you want to include in your Blueprint, use object mounts. Objects are stored in Runloop’s storage and can be reused across multiple Blueprints.If your storage object has a TTL set, ensure it won’t expire before your blueprint build completes. For persistent assets, consider creating objects without a TTL.
Code Mounts
To add a CodeMount to your Blueprint:token field is used for private repository authentication - include a GitHub Personal Access Token (PAT) with appropriate permissions.
File Mounts
Thefile_mounts parameter lets you add individual files to your Blueprint. The key is the path to the file in the devbox and the value is the content of the file. By default, blueprints are constructed by user and /home/user/ is where files are allowed to be mounted.
Mounting Files to Root
If you want to mount files to root, you will need to specify building the blueprint as root vialaunch_parameters:
Next Steps
- Customize with Dockerfiles - Use custom Dockerfiles, secrets, and composable blueprints
- Configure network policies - Restrict network access during build and runtime
- Manage blueprint lifecycle - Delete blueprints and configure launch parameters
