{"meta":{"title":"Running jobs in a container","intro":"Use a container to run the steps in a job.","product":"GitHub Actions","breadcrumbs":[{"href":"/en/actions","title":"GitHub Actions"},{"href":"/en/actions/how-tos","title":"How-tos"},{"href":"/en/actions/how-tos/write-workflows","title":"Write workflows"},{"href":"/en/actions/how-tos/write-workflows/choose-where-workflows-run","title":"Choose where workflows run"},{"href":"/en/actions/how-tos/write-workflows/choose-where-workflows-run/run-jobs-in-a-container","title":"Run jobs in a container"}],"documentType":"article"},"body":"# Running jobs in a container\n\nUse a container to run the steps in a job.\n\n## Overview\n\nUse `jobs.<job_id>.container` to create a container to run any steps in a job that don't already specify a container. If you have steps that use both script and container actions, the container actions will run as sibling containers on the same network with the same volume mounts.\n\nIf you do not set a `container`, all steps will run directly on the host specified by `runs-on` unless a step refers to an action configured to run in a container.\n\n> \\[!NOTE]\n> The default shell for `run` steps inside a container is `sh` instead of `bash`. This can be overridden with [`jobs.<job_id>.defaults.run`](/en/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_iddefaultsrun) or [`jobs.<job_id>.steps[*].shell`](/en/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idstepsshell).\n\n### Example: Running a job within a container\n\n```yaml copy\nname: CI\non:\n  push:\n    branches: [ main ]\njobs:\n  container-test-job:\n    runs-on: ubuntu-latest\n    container:\n      image: node:18\n      env:\n        NODE_ENV: development\n      ports:\n        - 80\n      volumes:\n        - my_docker_volume:/volume_mount\n      options: --cpus 1\n    steps:\n      - name: Check for dockerenv file\n        run: (ls /.dockerenv && echo Found dockerenv) || (echo No dockerenv)\n```\n\nWhen you only specify a container image, you can omit the `image` keyword.\n\n```yaml\njobs:\n  container-test-job:\n    runs-on: ubuntu-latest\n    container: node:18\n```\n\n### Dockerfile instructions and overrides\n\nA Dockerfile contains instructions and arguments that define the contents and startup behavior of a Docker container. For more information about the instructions Docker supports, see [Dockerfile reference](https://docs.docker.com/engine/reference/builder/) in the Docker documentation.\n\nSome Docker instructions interact with GitHub Actions, and an action's metadata file can override some Docker instructions. Ensure that you are familiar with how your Dockerfile interacts with GitHub Actions to prevent any unexpected behavior.\n\nFor reference information, see [Dockerfile support for GitHub Actions](/en/actions/reference/workflows-and-actions/dockerfile-support).\n\n## Defining the container image\n\nUse `jobs.<job_id>.container.image` to define the Docker image to use as the container to run the action. The value can be the Docker Hub image name or a registry name.\n\n> \\[!NOTE]\n> Docker Hub normally imposes rate limits on both push and pull operations which will affect jobs on self-hosted runners. However, GitHub-hosted runners are not subject to these limits based on an agreement between GitHub and Docker.\n\n## Defining credentials for a container registry\n\nIf the image's container registry requires authentication to pull the image, you can use `jobs.<job_id>.container.credentials` to set a `map` of the `username` and `password`. The credentials are the same values that you would provide to the [`docker login`](https://docs.docker.com/engine/reference/commandline/login/) command.\n\n### Example: Defining credentials for a container registry\n\n```yaml\ncontainer:\n  image: ghcr.io/owner/image\n  credentials:\n     username: ${{ github.actor }}\n     password: ${{ secrets.github_token }}\n```\n\n## Using environment variables with a container\n\nUse `jobs.<job_id>.container.env` to set a `map` of environment variables in the container.\n\n## Exposing network ports on a container\n\nUse `jobs.<job_id>.container.ports` to set an `array` of ports to expose on the container.\n\n## Mounting volumes in a container\n\nUse `jobs.<job_id>.container.volumes` to set an `array` of volumes for the container to use. You can use volumes to share data between services or other steps in a job. You can specify named Docker volumes, anonymous Docker volumes, or bind mounts on the host.\n\nTo specify a volume, you specify the source and destination path:\n\n`<source>:<destinationPath>`.\n\nThe `<source>` is a volume name or an absolute path on the host machine, and `<destinationPath>` is an absolute path in the container.\n\n### Example: Mounting volumes in a container\n\n```yaml\nvolumes:\n  - my_docker_volume:/volume_mount\n  - /data/my_data\n  - /source/directory:/destination/directory\n```\n\n## Setting container resource options\n\nUse `jobs.<job_id>.container.options` to configure additional Docker container resource options. For a list of options, see [`docker create` options](https://docs.docker.com/engine/reference/commandline/create/#options).\n\n> \\[!WARNING]\n> The `--network` and `--entrypoint` options are not supported."}