Latchbio Integration

Operations, Registration, Debugging, and Execution

This reference targets the current stable CLI and SDK (latch==2.77.1).

Authenticate and Select a Workspace

latch login
latch workspace

Select a known workspace by numeric ID:

latch workspace --id 12345

The active workspace controls unqualified latch:/// paths, Registry access, workflow registration, and programmatic execution. Surface it before a destructive or costly action.

Do not read or print ~/.latch/token. Use the CLI's supported login and token handling.

Registration

Basic remote registration:

latch register --yes --open .

Remote builds are the default:

latch register --remote .

Use a local Docker build only when intentional:

latch register --no-remote .

Important options:

# Register into another workspace
latch register --workspace-id 12345 .

# Mark the version as a release
latch register --mark-as-release .

# Register workflows from a non-default Python module
latch register --workflow-module wf.custom_entrypoint .

# Use a specific Dockerfile
latch register --dockerfile Dockerfile.release .

# Plain build output for CI logs
latch register --docker-progress plain .

Version behavior

Registration combines the project version with automatic content/version information unless disabled. Do not disable automatic versioning merely to force an overwrite.

An ordinary duplicate workflow registration exits with status 2. A duplicate staging version exits with status 1, which also covers build failures; inspect the diagnostic instead of applying the ordinary-registration exit-code rule to staging.

Release behavior

Before --mark-as-release:

• Pin SDK, Python, system, and scientific dependencies.

• Record tool and database versions.

• Run a representative launch plan.

• Confirm result links and metadata.

• Verify the source commit is clean and reproducible.

Private Workflow Images

SDK 2.77.1 supports an explicit workspace for image upload and listing:

latch image ls --workspace-id 12345
latch image upload my-workflow:1.0 --workspace-id 12345 --yes

Upload expects the image to exist in the local Docker daemon. To fetch an image intentionally, add --pull and use its full trusted registry reference. Since 2.77.0, a missing local image is no longer pulled implicitly.

An upload exits 0 when the push and Latch record both succeed, 1 when the push fails, and 3 when the image was pushed but recording it in Latch failed. The record is idempotent, so retry the same reference/name/version after status 3; an immutable registry tag can require a new version on retry. Preserve the reported digest to identify the exact uploaded image. An empty latch image ls result is a successful exit 0; status messages use stderr.

Staging and Development Shell

Build an image without publishing a workflow version:

latch register --staging .

In 2.77.1, the staging branch ignores --workspace-id and uses the active workspace. Select the target using latch workspace --id 12345 before staging. It also does not generate entrypoints from --nf-script or --snakefile; prepare the version-compatible entrypoint first.

Open a remote interactive shell in that image:

latch develop .

Choose a development instance:

latch develop . --instance-size small_gpu_task

Use latch develop --help to inspect the installed version's supported sizes.

Sync behavior

• Local files under the workflow root are synced into the container.

• Files outside that root are not synced.

• Local updates overwrite corresponding container files.

• Local deletions do not remove existing container files.

• Container-side edits are not synced back and can be overwritten.

• .gitignore and .dockerignore are respected.

• Re-run staging registration after changing the Dockerfile or dependencies.

Place small test fixtures under the project root and exclude private or large data from registration archives.

Debug a Running Task

Open an interactive shell for an execution or task:

latch exec --execution-id <execution-id>

For a Nextflow work directory:

latch nextflow attach --execution-id <execution-id>

Use interactive access for diagnosis, not for modifying the source of record. Reproduce and fix the issue locally, then register a new version.

Programmatic Execution

The old latch launch CLI is deprecated. Use latch_cli.services.launch.launch_v2.

Launch with Python parameters

import asyncio

from latch.types import LatchFile
from latch_cli.services.launch.launch_v2 import launch

execution = launch(
    wf_name="my_workflow",
    version="1.2.3-abcd12",
    params={
        "reads": LatchFile("latch:///test-data/reads.fastq.gz"),
        "minimum_quality": 20,
    },
)

completed = asyncio.run(asyncio.wait_for(execution.wait(), timeout=3600))
if completed is None:
    raise RuntimeError("execution polling ended without a result")
if completed.status != "SUCCEEDED":
    raise RuntimeError(
        f"execution {completed.id} ended with {completed.status}"
    )

print(completed.output)
print([path.path for path in completed.ingress_data])

The timeout limits asynchronous polling; synchronous SDK network requests may exceed it. A local polling timeout does not cancel paid compute: retain the execution ID, check status in the Console, and explicitly abort only if intended.

Only use this API with trusted registered workflow definitions: typed metadata is deserialized by the SDK, including when best_effort=True.

wf_name is the registered workflow name (check .latch/workflow_name or the Console), not the human-readable metadata display name.

launch defaults best_effort=True, allowing compatible dictionaries, dataclasses, strings for enum values, and other schema-guided conversions. Set best_effort=False only when the caller imports exactly the same Python types as the registered workflow.

Compatibility:

• Programmatic launch requires workflows registered with SDK 2.62.0+.

• Typed output decoding requires workflows registered with SDK 2.65.1+.

• Python versions and imported classes must remain compatible for strict serialized type decoding.

Launch a registered launch plan

import asyncio

from latch_cli.services.launch.launch_v2 import launch_from_launch_plan

execution = launch_from_launch_plan(
    wf_name="my_workflow",
    version="1.2.3-abcd12",
    lp_name="Small public example",
)

completed = asyncio.run(asyncio.wait_for(execution.wait(), timeout=3600))
if completed is None or completed.status != "SUCCEEDED":
    raise RuntimeError("launch-plan execution did not succeed")

Poll or abort

Execution exposes:

• id

• status

• poll() (a generator; calling it alone does not fetch status)

• async wait()

• abort()

Abort only the intended active execution:

next(execution.poll())  # Refresh status once; continuous polling needs a delay.
if execution.status not in {"SUCCEEDED", "FAILED", "ABORTED", "SKIPPED", "ABORTING"}:
    execution.abort()

Interactive Execution Through MCP

When Latch MCP is available:

1. List workspaces.

2. List workflows.

3. Fetch the selected workflow schema.

4. Validate parameters.

5. Obtain confirmation for paid compute.

6. Launch.

7. Poll execution state.

8. Fetch task logs only for relevant failed or running nodes.

MCP authorization is separate from SDK login. See references/latch-mcp.md.

Monitoring

Console execution monitoring provides:

• Overall execution status

• Graph and task-node status

• Inputs and outputs

• Logs

• Provenance and result files

• Resource monitoring

The 2.77.1 CLI still provides the following deprecated command:

latch get-executions

The official CLI guide says it will be removed in a future version. Prefer the Console or Latch MCP for new monitoring integrations.

For every production workflow, emit:

• Concise message() calls for actionable warnings and errors

• Result links for high-value outputs

• Normal structured logs for detailed diagnostics

Do not log secrets or signed URLs.

Troubleshooting

Authentication failure

latch login
latch workspace

Confirm the workspace is the one containing the data, workflow, and Registry objects. Do not attempt to repair authentication by modifying token files.

Registration cannot find the workflow

• Confirm the workflow root and wf package.

• Check --workflow-module.

• Compile the Python package.

• Verify metadata imports do not perform network calls.

• Inspect task-specific Dockerfile arguments; they must be string literals.

Build failure

• Reproduce through staging registration.

• Use --docker-progress plain.

• Check .dockerignore did not omit required files.

• Confirm system packages and architecture.

• Use --no-remote only when the local Docker environment is known-good.

Runtime import or executable failure

• Enter latch develop.

• Check which python3, installed packages, $PATH, and executable permissions.

• Run the task-level test script inside the image.

• Rebuild staging after dependency changes.

Out of memory or storage

• Inspect resource monitoring.

• Measure peak rather than average use.

• Adjust one resource dimension at a time.

• See references/resource-configuration.md.

Programmatic launch type error

• Fetch the workflow's current schema/version.

• Verify every required parameter.

• Use best_effort=True for compatible external representations.

• Re-register old workflows with a current SDK when typed outputs are needed.

Official Sources

• CLI commands: https://wiki.latch.bio/workflows/sdk/cli/commands

• Development and debugging: https://wiki.latch.bio/workflows/sdk/testing-and-debugging-a-workflow/development-and-debugging

• Programmatic execution: https://wiki.latch.bio/workflows/sdk/testing-and-debugging-a-workflow/programmatic-execution

• Execution monitoring: https://wiki.latch.bio/workflows/sdk/console/execution-monitoring

• Resource monitoring: https://wiki.latch.bio/workflows/sdk/console/resource-monitoring

• Versioning: https://wiki.latch.bio/workflows/sdk/console/versioning

• CLI source in the 2.77.1 release commit: https://github.com/latchbio/latch/blob/b3768e65c6d496868f6e530f11977d857ad85dc7/src/latch_cli/main.py