> For the complete documentation index, see [llms.txt](https://docs.release.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.release.com/reference-documentation/application-settings/workspaces.md). # Workspaces ## Overview Release Workspaces provide multiple containers within your environment or runnable job with access to a common filesystem. This filesystem can be made up of both regular shared files that can be created and modified by your containers or mounts of external resources such as cloud storage buckets (S3, GCS, etc.) or Git repositories. ## Defining Workspaces ### Single Auto-Attached Workspace In most cases all you'll need is a single workspace per environment that you'll want automatically attached to all of your containers. The recommended basic configuration is: ```yaml workspaces: - name: default auto_attach: true path: /workspace ``` By setting `auto_attach: true`, the workspace will be automatically attached to every job and service defined in your Application Template and accessible from `/workspace` within the container's filesytem. ### Multiple Workspaces (Advanced) In more advanced cases you may want to have multiple workspaces and control which jobs and services have access to which workspaces. Here's an example configuration: ```yaml workspaces: - name: frontend path: /assets - name: backend path: /assets services: - name: frontend image: frontend-server workspaces: - frontend - name: backend image: backend-server workspaces: - backend jobs: - name: build-frontend-assets image: build-frontend workspaces: - frontend - name: build-backend-assets image: build-backend workspaces: - backend ``` In this example, both the `backend`-related server and build job and the `frontend`-related server and build job each have access to a shared `/assets` directories but because they are in different workspaces, they're completely isolated filesystems. ## Use Cases ### Sharing files between jobs A common use case is when a pipeline of jobs all need to work on files produced by previous jobs in the pipeline. Workspaces can make this simple by providing a known location to read/write files. Example: ```yaml workspaces: - name: default auto_attach: true path: /workspace jobs: # Downloads a model and writes it to /workspace/model - name: download image: download-model # Finetunes the model at /workspace/model and writes it to /workspace/model-finetuned - name: finetune image: finetune-model services: # Runs an inference server for the finetuned model from /workspace/model-finetuned - name: serve image: serve-model workflows: - name: setup parallelize: - step: download tasks: - jobs.download - step: finetune tasks: - jobs.finetune - step: serve tasks: - jobs.serve ``` ### Mounting Git repositories To make the contents of a Git repository available to one or more of your containers you can use [Workspace Mounts](/reference-documentation/application-settings/application-template/schema-definition.md#workspaces-3) Example: ```yaml workspaces: - name: default auto_attach: true path: /workspace mounts: - path: my-repo source_url: https://github.com/org/repo#branch services: # Runs a notebook with the code checked out at /workspaces/my-repo - name: notebook image: notebook ``` Note that writes to a Git repository mount are allowed but will be only visible locally. The container must commit and push to make the changes accessible remotely. To dynamically mount a Git repository based on user input, see [Parameters](/reference-documentation/application-settings/parameters.md). ### Mounting cloud storage buckets To make the contents of a cloud storage bucket available to one or more of your containers you can use [Workspace Mounts](/reference-documentation/application-settings/application-template/schema-definition.md#workspaces-3) Example: ```yaml workspaces: - name: default auto_attach: true path: /workspace mounts: - path: my-training-data source_url: s3://my-bucket/my/prefix/training-data jobs: # Runs a training job with the training data file available at # /workspaces/my-training-data - name: training image: training ``` To set S3 mount options, you can add query string parameters to your `source_url`. The query string parameters correspond directly to [the Mountpoint S3 configuration flags](https://github.com/awslabs/mountpoint-s3/blob/main/doc/CONFIGURATION.md). #### Explicitly setting the bucket region ```yaml workspaces: - name: default auto_attach: true path: /workspace mounts: - path: my-training-data source_url: s3://my-bucket/my/prefix/training-data?region=us-west-2 ``` #### Mounting a public S3 bucket To mount a public S3 bucket, disable request signing and set the bucket region. For example, to mount [this public dataset of Southern California Earthquake Data](https://registry.opendata.aws/southern-california-earthquakes/) you'd specify the `source_url` as: ```yaml workspaces: - name: default auto_attach: true path: /workspace mounts: - source_url: s3://scedc-pds?no-sign-request®ion=us-west-2 path: /sc-earthquake-data ``` To dynamically mount a cloud storage bucket or file based on user input or a file upload, see [Parameters](/reference-documentation/application-settings/parameters.md). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.release.com/reference-documentation/application-settings/workspaces.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.