Skip to main content

Container Images

Every Job and Server runs from a container image. The image defines the operating system, dependencies, and optionally the application code. Anycloud provisions the VM and runs the image; it does not build the image for you.

Choose an image workflow​

Use a public image when it already contains the runtime you need:

anycloud submit pytorch/pytorch:2.2.0-cuda12.1-cudnn8-runtime \
  --gpu-type h100 \
  --gpus all \
  -- python -c "import torch; print(torch.cuda.is_available())"

Use a stable dependency image with @anycloud.function() or @anycloud.serve() when Python code changes frequently. Anycloud clones the exact pushed Git commit at startup, so the image only needs the runtime, dependencies, and git.

Build a custom image when you need a hermetic application artifact, a non-Python workload, or dependencies unavailable in a public image.

Build and publish​

A minimal image:

FROM python:3.11-slim

WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .

CMD ["python", "main.py"]

Cloud workload VMs run Linux on x86-64. Specify linux/amd64, especially when building on Apple Silicon:

docker buildx build \
  --platform linux/amd64 \
  -t ghcr.io/YOUR_GITHUB_USERNAME/my-app:latest \
  --push .

anycloud login authenticates the local Docker CLI to GHCR when Docker is installed. Public images can come from any registry; private image authentication currently supports GHCR.

For repeatable builds, publish in CI and tag the image with a commit SHA:

name: build-image
on: push
jobs:
  build:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write
    steps:
      - uses: actions/checkout@v6
      - run: echo "IMAGE=ghcr.io/${GITHUB_REPOSITORY,,}" >> "$GITHUB_ENV"
      - uses: docker/login-action@v4
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
      - uses: docker/build-push-action@v7
        with:
          context: .
          platforms: linux/amd64
          push: true
          tags: ${{ env.IMAGE }}:${{ github.sha }}

GPU images​

Start from a CUDA, NVIDIA, or framework GPU image that matches the libraries your application expects. Anycloud prepares GPU access on the host when you request GPU hardware; the container does not need to install a host driver or set --runtime nvidia.

Building on macOS does not test GPU access. Compile CUDA extensions in a supported Linux build environment and avoid Docker build steps that require a live GPU on a CPU-only CI runner.

Pull and startup behavior​

Anycloud resolves the requested reference to a registry digest before the workload starts. A mutable tag can point to new content, but each deployment pulls the digest resolved for that run.

On supported GPU hosts, the pull path can fetch several ranges of a large layer concurrently. Unsupported configurations and transfer failures fall back to a normal Docker pull. No workload flag is required.

Every image byte must reach a new VM before startup. To reduce cold starts:

  • Use runtime images instead of development images when compilers are not needed at run time.
  • Use multi-stage builds and a .dockerignore.
  • Remove package indexes and build caches in the same layer that creates them.
  • Install Python packages with pip --no-cache-dir.
  • Keep datasets and model weights in Buckets when their lifecycle differs from the application.
  • Keep frequently changing Python source in the Git-sync workflow when appropriate.

Measure compressed registry size and time to first useful work before and after changes; moving bytes between an image and a Bucket changes when they transfer, not whether they transfer.

Runtime options​

Anycloud passes common container resource settings through to Docker:

anycloud submit ghcr.io/acme/train:latest \
  --shm-size 8g \
  --memory 32g \
  --cpus 4 \
  --ipc host \
  --gpus all

See submit reference or Configuration for the exact fields.