/by-deploy-compute

id: "skill_b7bd2add94d84922a8d7141b635a4d89"
name: "by-deploy-compute"
display-name: "BY Deploy Compute"
short-description: "Set up structure-prediction and antibody/binder design tools on user-owned compute — local GPU, RunPod, Modal, or generic SLURM/PBS HPC. Use when bootstrapping a new BY workstation, adding a tool (Protenix, BoltzGen, PXDesign, RFAntibody, etc.) to an existing environment, or migrating away from Tamarind cloud."
category: "deployment"
keywords: "deployment, local GPU, RunPod, Modal, HPC, SLURM, CUDA, Docker, Protenix, BoltzGen, PXDesign, RFAntibody, ImmuneBuilder, ThermoMPNN, Boltz-2, AlphaFold, weights, conda, env"
version: "1.0"
last-updated: "2026-05-20"

BY Deploy Compute Skill

BY is a **local-first** agent. The default compute provider is `"local"` (see `.by/config.json` → `compute.default_provider`). This skill teaches you how to stand up each design and folding tool on hardware **the user owns or pays for directly** — a personal GPU workstation, a RunPod pod, a Modal app, or a generic SLURM/PBS cluster — so campaigns run without depending on a managed cloud provider.

Tamarind remains available as a cloud fallback when local compute is unavailable. It is never the default; users opt in explicitly via `compute.default_provider = "tamarind"`.

When to Use This Skill

Use this skill when you have:

• ✅ **A fresh BY workstation** that needs Protenix / BoltzGen / PXDesign installed for the first time
• ✅ **An existing local install missing a tool** (e.g., ThermoMPNN, RFAntibody, ImmuneBuilder) that an active campaign now requires
• ✅ **A RunPod account** and want a per-tool deployment recipe with pod template, persistent volumes, and a working `entry_command`
• ✅ **A Modal account** and want a `modal.Image` recipe with HuggingFace secret wiring and weight-cache volumes
• ✅ **An institutional HPC** (SLURM or PBS) and want a portable submission script that loads CUDA modules, activates a conda env, and runs the tool
• ✅ **A user migrating away from Tamarind** — concrete, copy-pasteable replacement deployments for every tool they currently call
• ✅ **A failed local invocation** that needs to be diagnosed as a deployment issue (missing weights, wrong CUDA, OOM) vs a tool-internal bug

Do NOT use this skill when:

• ❌ **You just need to run a tool that is already installed** — invoke the engine skill (`protenix`, `boltzgen`, `pxdesign`) directly.
• ❌ **You are debugging tool-internal results** (low ipSAE, high RMSD) — use `by-scoring` or `by-failure-diagnosis`. Deployment is upstream of result quality.
• ❌ **The user has explicitly chosen Tamarind** (`compute.default_provider = "tamarind"`) — call the Tamarind MCP path; don't try to deploy locally first.
• ❌ **The campaign is already running** and just needs a status check — that's `by-campaign-manager` or `/by:watch`.
• ❌ **You need to allocate a campaign directory** — that is `by-session` / `by-campaign-manager`.
• ❌ **The question is "which tool should I use"** — that is `by-design-workflow`; deployment is per-tool plumbing, not strategy.

Quick Start

User: "Set up Protenix on my workstation. I have an RTX 4090."

Agent:
  1. Run scripts/check_gpu_env.sh → confirms CUDA 12.1, 24GB free
  2. Look up Protenix in the Tool Catalog → 16-24 GB recommended, OK
  3. Render scripts/deploy_tool_template.yaml with target=local, tool=protenix
  4. Clone repo + download weights to the path in `.by/config.json` compute.local.protenix.path
  5. Create conda env per references/local-gpu-setup.md
  6. Smoke-test: predict 6OFS chain A; expect a .cif file + confidence JSON in under 5 minutes
  7. Update .by/config.json compute.local.protenix.{path,conda_env,binary}
  8. Done — campaigns now resolve Protenix locally.

User: "Deploy BoltzGen on RunPod, I don't have a local GPU."

Agent:
  1. Confirm RUNPOD_API_KEY is set (refuse if missing — direct to references/runpod-setup.md)
  2. Choose pod template: PyTorch 2.4 + CUDA 12.4, GPU = A40 (48 GB)
  3. Mount persistent volume `/runpod-volume` for weights cache
  4. Render scripts/deploy_tool_template.yaml with target=runpod, tool=boltzgen
  5. Run scripts/runpod_deploy.py deploy_boltzgen.yaml → returns pod_id + endpoint URL
  6. Update .by/config.json compute.hpc.endpoint_url
  7. Done — design agent now resolves BoltzGen against the RunPod endpoint.

Installation

This skill itself has no Python dependencies beyond stdlib. The tools it deploys each have their own dependency graphs documented in their respective upstream repos. The table below lists what the **scripts in this skill** require.

| Software | Version | License | Commercial Use | Installation | |----------|---------|---------|----------------|--------------| | Python | ≥ 3.10 | PSF | ✅ Permitted | system / conda | | PyYAML | ≥ 6.0 | MIT | ✅ Permitted | `pip install pyyaml` | | requests | ≥ 2.31 | Apache-2.0 | ✅ Permitted | `pip install requests` | | bash | ≥ 4.0 (Linux) / 3.2 (macOS) | GPLv3 | ✅ Permitted | system | | Docker (optional) | ≥ 24.0 | Apache-2.0 | ✅ Permitted | docker.com | | nvidia-driver | ≥ 535 (CUDA 12.x) | NVIDIA EULA | ✅ Permitted (binary use) | nvidia.com | | CUDA Toolkit | 12.1 or 12.4 | NVIDIA EULA | ✅ Permitted | developer.nvidia.com |

**License Compliance:** All packages and runtimes in this table permit commercial use in AI applications. The per-tool license is documented in each tool's upstream repository — check before commercial deployment.

**System requirements:**

• Linux x86_64 (Ubuntu 22.04 LTS recommended) for any NVIDIA-GPU workflow
• macOS (Apple Silicon) only supports a subset of tools via MPS or CPU-only fallback paths
• For RunPod: outbound HTTPS to `api.runpod.io` and a funded account
• For Modal: outbound HTTPS to `api.modal.com` and `modal token new` completed
• For HPC: ssh access, a working conda or module system, and a GPU partition

Inputs

**Required:**

• **Target deployment surface** — exactly one of `local`, `runpod`, `modal`, `hp