Choose code and dependencies

Pick the right packaging mode for standalone scripts, Python packages, native profiles and containers.

Choose how your job's code and Python dependencies are packaged and executed on a worker.

1. Pick how to supply your code

What you are running	How to submit it	Best for
Single `.py` script	`ct-cli submit script.py`	Quick experiments, one-off analysis, or testing
Local Python project	`ct-cli program publish ./my-pkg ...`	Reusable functions with a `pyproject.toml` and `uv.lock`
Git repository	`--git-url ... --git-ref main`	Pinning a calculation to an exact Git commit
Published Program	`ct-cli submit my-program@1 --params ...`	Production workflows called repeatedly with new inputs

When you reference a Git repository, the platform resolves the branch or tag to an exact commit SHA at submission time so future pushes never alter an already-submitted job.

2. Choose how dependencies are installed

There are three ways a worker can provide Python libraries for your job:

Managed `uv` environment (default for scripts and small packages)

The worker automatically creates or reuses a cached uv environment matching your script's inline PEP 723 metadata or your project's pyproject.toml and uv.lock.

Shared native profile (`compute/runtime`)

Our scientific packages (DFT, MD, TS search, and benchmarks) share a single locked Python 3.13 environment (compute/runtime, with CUDA 13 on Linux GPU workers). Using a native profile skips per-job installation for heavy scientific libraries:

Important: Native profiles verify the installed environment fingerprint before running a job. Always stop the worker before modifying or syncing packages in compute/runtime.

Docker container execution

Container jobs run inside a fresh Docker container per attempt, combining prebuilt system/C++ dependencies from the base image with your pinned Python source. Both native and container runs use the exact same Program input validation and artifact collection.

3. Separate code versions from placement

Your code/dependencies and your target hardware are configured independently:

Program version (name@1 → name@2): Captures code, Pydantic schemas, and dependency lock.
Pool & resources (--pool, --cpus, --gpus, --memory): Selects which registered workers can pick up the job.

4. Keep working directories stateless

Workers run each job attempt in a fresh temporary scratch directory:

Never hardcode paths to files outside the job workspace.
Stage input files explicitly and write any file you want to keep under results/ (see Work with files and results).