Command Line Interface#

Cluster CLI#

sky launch#

Launch a cluster or task.

If ENTRYPOINT points to a valid YAML file, it is read in as the task specification. Otherwise, it is interpreted as a bash command.

In both cases, the commands are run under the task’s workdir (if specified) and they undergo job queue scheduling.

With --resize, scale an existing cluster up or down to --num-nodes. Scale-up adds new workers while preserving existing nodes. Scale-down requires no running jobs and re-provisions workers to the new count.

Examples:

# Resize an existing cluster to 4 nodes.
sky launch -c my-cluster --resize --num-nodes 4

# Resize using a YAML that specifies num_nodes.
sky launch -c my-cluster --resize cluster.yaml

sky launch [OPTIONS] [ENTRYPOINT]...

Options

--config <config>#

Path to a config file or a single key-value pair. To add multiple key-value pairs add multiple flags (e.g. –config nested.key1=val1 –config nested.key2=val2).

-c, --cluster <cluster>#

A cluster name. If provided, either reuse an existing cluster with that name or provision a new cluster with that name. Otherwise provision a new cluster with an autogenerated name.

--dryrun#

If True, do not actually run the job.

-d, --detach-run, -no-d#

If True, as soon as a job is submitted, return from this call and do not stream execution logs.

-n, --name <name>#

Task name. Overrides the “name” config in the YAML if both are supplied.

--workdir <workdir>#

If specified, sync this dir to the remote working directory, where the task will be invoked. Overrides the “workdir” config in the YAML if both are supplied.

--infra <infra>#

Infrastructure to use. Format: cloud, cloud/region, cloud/region/zone, k8s/context-name, or ssh/node-pool-name. Examples: aws, aws/us-east-1, aws/us-east-1/us-east-1a, aws/*/us-east-1a, k8s/my-context, ssh/my-nodes.

--num-nodes <num_nodes>#

Number of nodes to execute the task on. Overrides the “num_nodes” config in the YAML if both are supplied.

--cpus <cpus>#

Number of vCPUs each instance must have (e.g., --cpus=4 (exactly 4) or --cpus=4+ (at least 4)). This is used to automatically select the instance type.

--memory <memory>#

Amount of memory each instance must have in GB (e.g., --memory=16 (exactly 16GB), --memory=16+ (at least 16GB))

--disk-size <disk_size>#

OS disk size in GBs.

--disk-tier <disk_tier>#

OS disk tier. Could be one of low, medium, high, ultra, best, none. If best is specified, use the best possible disk tier. If none is specified, enforce to use default value and override the option in task YAML. Default: medium

Options:

low | medium | high | ultra | best | none

--network-tier <network_tier>#

Network tier. Could be one of standard, best. If best is specified, use the best network tier available on the specified instance. Default: standard

Options:

standard | best

--use-spot, --no-use-spot#

Whether to request spot instances. If specified, overrides the “resources.use_spot” config.

--image-id <image_id>#

Custom image id for launching the instances. Passing “none” resets the config.

--env-file <env_file>#

Path to a dotenv file with environment variables to set on the remote node.

If any values from --env-file conflict with values set by --env, the --env value will be preferred.

Values from --env-file will also load to secrets with lower preference compared to --secret or --secret-file.

--env <env>#

Environment variable to set on the remote node. It can be specified multiple times. Examples:

1. --env MY_ENV=1: set $MY_ENV on the cluster to be 1.

2. --env MY_ENV2=$HOME: set $MY_ENV2 on the cluster to be the same value of $HOME in the local environment where the CLI command is run.

3. --env MY_ENV3: set $MY_ENV3 on the cluster to be the same value of $MY_ENV3 in the local environment.

--secret-file <secret_file>#

Path to a dotenv file with secret variables to set on the remote node.

If any values from --secret-file conflict with values set by --secret, the --secret value will be preferred.

--secret <secret>#

Secret variable to set on the remote node. These variables will be redacted in logs and YAML outputs for security. It can be specified multiple times. Examples:

1. --secret API_KEY=secret123: set $API_KEY on the cluster to
be secret123.

2. --secret JWT_SECRET: set $JWT_SECRET on the cluster to be the same value of $JWT_SECRET in the local environment.

--local-disk <local_disk>#

Local (instance) storage requirement. Format: [mode:]size[+] or mode. Mode is “nvme” (default) or “ssd”. Size is total GB across all disks. If only mode specified, size defaults to 100+. If only size specified, mode defaults to nvme. Examples:

1. --local-disk nvme:1000+: NVMe SSD with at least 1TB total.

  1. --local-disk ssd:500: SSD with exactly 500GB total.

  2. --local-disk nvme: Any NVMe instance (at least 100GB).

  3. --local-disk 1000+: NVMe (default) with at least 1TB.

Note: Local storage is ephemeral and lost when the instance terminates.

--gpus <gpus>#

Type and number of GPUs to use. Example values: “V100:8”, “V100” (short for a count of 1), or “V100:0.5” (fractional counts are supported by the scheduling framework). If a new cluster is being launched by this command, this is the resources to provision. If an existing cluster is being reused, this is seen as the task demand, which must fit the cluster’s total resources and is used for scheduling the task. Overrides the “accelerators” config in the YAML if both are supplied. Passing “none” resets the config.

-t, --instance-type <instance_type>#

The instance type to use. If specified, overrides the “resources.instance_type” config. Passing “none” resets the config.

--ports <ports>#

Ports to open on the cluster. Accepts a single port (--ports 8080), a range (--ports 8000-8010), or a comma-separated list (--ports 8080,9090). Repeat the flag to specify multiple values (--ports 8080 --ports 9090-9100). If specified, overrides the “ports” config in the YAML.

--priority <priority>#

Priority for this task. Accepts either an integer (from -1000 to 1000, or a string priority class name. Passing “none” clears both.

--async, --no-async#

Run the command asynchronously.

-i, --idle-minutes-to-autostop <idle_minutes_to_autostop>#

Automatically stop the cluster after this many minutes of idleness, i.e., no running or pending jobs in the cluster’s job queue. Idleness gets reset depending on the --wait-for flag. Setting this flag is equivalent to running sky launch -d ... and then sky autostop -i <minutes>. If not set, the cluster will not be autostopped.

--wait-for <wait_for>#

Determines the condition for resetting the idleness timer. This option works in conjunction with --idle-minutes-to-autostop. Options:

1. jobs_and_ssh (default): Wait for in-progress jobs and SSH connections to finish.
2. jobs: Only wait for in-progress jobs.
3. none: Wait for nothing; autostop right after idle-minutes-to-autostop.
Options:

jobs_and_ssh | jobs | none

--down#

Autodown the cluster: tear down the cluster after all jobs finish (successfully or abnormally). If –idle-minutes-to-autostop is also set, the cluster will be torn down after the specified idle time. Note that if errors occur during provisioning/data syncing/setting up, the cluster will not be torn down for debugging purposes.

-r, --retry-until-up#

Whether to retry provisioning infinitely until the cluster is up, if we fail to launch the cluster on any possible region/cloud due to unavailability errors.

-y, --yes#

Skip confirmation prompt.

--no-setup#

Skip setup phase when (re-)launching cluster.

--clone-disk-from, --clone <clone_disk_from>#

[Experimental] Clone disk from an existing cluster to launch a new one. This is useful when the new cluster needs to have the same data on the boot disk as an existing cluster.

--fast#

[Experimental] If the cluster is already up and available, skip provisioning and setup steps.

--resize#

Resize an existing cluster to –num-nodes. Supports both scale-up (adding workers) and scale-down (removing workers). Scale-down requires no running jobs. Requires -c to specify an existing cluster.

--git-url <git_url>#

Git repository URL.

--git-ref <git_ref>#

Git reference (branch, tag, or commit hash) to use.

-w, --workspace <workspace>#

Workspace to launch into. Shorthand for –config active_workspace=<name>.

Arguments

ENTRYPOINT#

Optional argument(s)

sky stop#

Stop cluster(s).

CLUSTER is the name (or glob pattern) of the cluster to stop. If both CLUSTER and --all are supplied, the latter takes precedence.

Data on attached disks is not lost when a cluster is stopped. Billing for the instances will stop, while the disks will still be charged. Those disks will be reattached when restarting the cluster.

Currently, spot instance clusters cannot be stopped.

Examples:

# Stop a specific cluster.
sky stop cluster_name

# Stop multiple clusters.
sky stop cluster1 cluster2

# Stop all clusters matching glob pattern 'cluster*'.
sky stop "cluster*"

# Stop all existing clusters.
sky stop -a

sky stop [OPTIONS] [CLUSTERS]...

Options

--config <config>#

Path to a config file or a single key-value pair. To add multiple key-value pairs add multiple flags (e.g. –config nested.key1=val1 –config nested.key2=val2).

-a, --all#

Stop all existing clusters.

-u, --all-users#

Stop all existing clusters for all users.

-y, --yes#

Skip confirmation prompt.

--graceful#

Wait for MOUNT_CACHED uploads to complete before stopping/terminating. Will cancel current jobs first.

--graceful-timeout <graceful_timeout>#

Timeout in seconds for –graceful flag. When not set, will wait for MOUNT_CACHED uploads until they are finished.

--async, --no-async#

Run the command asynchronously.

Arguments

CLUSTERS#

Optional argument(s)

sky start#

Restart cluster(s).

If a cluster is previously stopped (status is STOPPED) or failed in provisioning/runtime installation (status is INIT), this command will attempt to start the cluster. In the latter case, provisioning and runtime installation will be retried.

Auto-failover provisioning is not used when restarting a stopped cluster. It will be started on the same cloud, region, and zone that were chosen before.

If a cluster is already in the UP status, this command has no effect.

Examples:

# Restart a specific cluster.
sky start cluster_name

# Restart multiple clusters.
sky start cluster1 cluster2

# Restart all clusters.
sky start -a

sky start [OPTIONS] [CLUSTERS]...

Options

--config <config>#

Path to a config file or a single key-value pair. To add multiple key-value pairs add multiple flags (e.g. –config nested.key1=val1 –config nested.key2=val2).

-a, --all#

Start all existing clusters.

-y, --yes#

Skip confirmation prompt.

-i, --idle-minutes-to-autostop <idle_minutes_to_autostop>#

Automatically stop the cluster after this many minutes of idleness, i.e., no running or pending jobs in the cluster’s job queue. Idleness gets reset depending on the --wait-for flag. Setting this flag is equivalent to running sky launch -d ... and then sky autostop -i <minutes>. If not set, the cluster will not be autostopped.

--wait-for <wait_for>#

Determines the condition for resetting the idleness timer. This option works in conjunction with --idle-minutes-to-autostop. Options:

1. jobs_and_ssh (default): Wait for in-progress jobs and SSH connections to finish.
2. jobs: Only wait for in-progress jobs.
3. none: Wait for nothing; autostop right after idle-minutes-to-autostop.
Options:

jobs_and_ssh | jobs | none

--down#

Autodown the cluster: tear down the cluster after specified minutes of idle time after all jobs finish (successfully or abnormally). Requires –idle-minutes-to-autostop to be set.

-r, --retry-until-up#

Retry provisioning infinitely until the cluster is up, if we fail to start the cluster due to unavailability errors.

-f, --force#

Force start the cluster even if it is already UP. Useful for upgrading the SkyPilot runtime on the cluster.

--async, --no-async#

Run the command asynchronously.

Arguments

CLUSTERS#

Optional argument(s)

sky down#

Tear down cluster(s).

CLUSTER is the name of the cluster (or glob pattern) to tear down. If both CLUSTER and --all are supplied, the latter takes precedence.

Tearing down a cluster will delete all associated resources (all billing stops), and any data on the attached disks will be lost. Accelerators (e.g., TPUs) that are part of the cluster will be deleted too.

Examples:

# Tear down a specific cluster.
sky down cluster_name

# Tear down multiple clusters.
sky down cluster1 cluster2

# Tear down all clusters matching glob pattern 'cluster*'.
sky down "cluster*"

# Tear down all existing clusters.
sky down -a

sky down [OPTIONS] [CLUSTERS]...

Options

--config <config>#

Path to a config file or a single key-value pair. To add multiple key-value pairs add multiple flags (e.g. –config nested.key1=val1 –config nested.key2=val2).

-a, --all#

Tear down all existing clusters.

-u, --all-users#

Tear down all existing clusters for all users.

-y, --yes#

Skip confirmation prompt.

-p, --purge#

(Advanced) Forcefully remove the cluster(s) from SkyPilot’s cluster table, even if the actual cluster termination failed on the cloud. WARNING: This flag should only be set sparingly in certain manual troubleshooting scenarios; with it set, it is the user’s responsibility to ensure there are no leaked instances and related resources.

--graceful#

Wait for MOUNT_CACHED uploads to complete before stopping/terminating. Will cancel current jobs first.

--graceful-timeout <graceful_timeout>#

Timeout in seconds for –graceful flag. When not set, will wait for MOUNT_CACHED uploads until they are finished.

--async, --no-async#

Run the command asynchronously.

Arguments

CLUSTERS#

Optional argument(s)

sky status#

Show clusters.

If CLUSTERS is given, show those clusters. Otherwise, show all clusters.

If –ip is specified, show the IP address of the head node of the cluster. Only available when CLUSTERS contains exactly one cluster, e.g. sky status --ip mycluster.

If –endpoints is specified, show all exposed endpoints in the cluster. Only available when CLUSTERS contains exactly one cluster, e.g. sky status --endpoints mycluster. To query a single endpoint, you can use sky status mycluster --endpoint 8888.

Running sky status will update the ssh config for the clusters locally, so that you can directly ssh into the clusters or connect to the clusters with vscode.

The following fields for each cluster are recorded: cluster name, time since last launch, resources, region, zone, hourly price, status, autostop, command.

Display all fields using sky status -v.

Each cluster can have one of the following statuses:

  • INIT: The cluster may be live or down. It can happen in the following cases:

    • Ongoing provisioning or runtime setup. (A sky launch has started but has not completed.)

    • Or, the cluster is in an abnormal state, e.g., some cluster nodes are down, or the SkyPilot runtime is unhealthy. (To recover the cluster, try sky launch again on it.)

  • UP: Provisioning and runtime setup have succeeded and the cluster is live. (The most recent sky launch has completed successfully.)

  • STOPPED: The cluster is stopped and the storage is persisted. Use sky start to restart the cluster.

Autostop column:

  • Indicates after how many minutes of idleness (no in-progress jobs) the cluster will be autostopped. ‘-’ means disabled.

  • If the time is followed by ‘(down)’, e.g., ‘1m (down)’, the cluster will be autodowned, rather than autostopped.

Getting up-to-date cluster statuses:

  • In normal cases where clusters are entirely managed by SkyPilot (i.e., no manual operations in cloud consoles) and no autostopping is used, the table returned by this command will accurately reflect the cluster statuses.

  • In cases where clusters are changed outside of SkyPilot (e.g., manual operations in cloud consoles; unmanaged spot clusters getting preempted) or for autostop-enabled clusters, use --refresh to query the latest cluster statuses from the cloud providers.

sky status [OPTIONS] [CLUSTERS]...

Options

--config <config>#

Path to a config file or a single key-value pair. To add multiple key-value pairs add multiple flags (e.g. –config nested.key1=val1 –config nested.key2=val2).

-v, --verbose#

Show all information in full.

-r, --refresh#

Query the latest cluster statuses from the cloud provider(s).

--ip#

Get the IP address of the head node of a cluster. This option will override all other options. For Kubernetes clusters, the returned IP address is the internal IP of the head pod, and may not be accessible from outside the cluster.

--endpoints#

Get all exposed endpoints and corresponding URLs for acluster. This option will override all other options.

--endpoint <endpoint>#

Get the endpoint URL for the specified port number on the cluster. This option will override all other options.

--show-managed-jobs, --no-show-managed-jobs#

Also show recent in-progress managed jobs, if any.

--show-services, --no-show-services#

Also show sky serve services, if any.

--show-pools, --no-show-pools#

Also show pools, if any.

-u, --all-users#

Show all clusters, including those not owned by the current user.

-o, --output <output_format>#

Output format. Choices: table, json. Default: table.

Options:

table | json

Arguments

CLUSTERS#

Optional argument(s)

sky autostop#

Schedule an autostop or autodown for cluster(s).

Autostop/autodown will automatically stop or teardown a cluster when it becomes idle for a specified duration.

CLUSTERS are the names (or glob patterns) of the clusters to stop. If both CLUSTERS and --all are supplied, the latter takes precedence.

Idleness time of a cluster is reset to zero, when any of these happens:

  • A job is submitted (sky launch or sky exec).

  • The cluster has restarted.

  • An autostop idle time is set.

  • An SSH session is active (To disable this, set --wait-for jobs).

To disable the idleness timer completely and set a hard time limit, set --wait-for none.

Example 1: say a cluster with autostop set to 2 hours has been idle for 1 hour, then autostop is reset to 30 minutes. The cluster will not be immediately autostopped. Instead, the idleness timer restarts counting when the second autostop setting of 30 minutes was submitted.

Example 2: say a cluster without any autostop set has been idle for 1 hour, then an autostop of 30 minutes is set. The cluster will not be immediately autostopped. Instead, the idleness timer only starts counting after the autostop setting was set.

Typical usage:

# Autostop this cluster after 60 minutes of idleness.
sky autostop cluster_name -i 60

# Cancel autostop for a specific cluster.
sky autostop cluster_name --cancel

# Autostop this cluster after 60 minutes, regardless of activity.
sky autostop cluster_name -i 60 --wait-for none

# Autodown this cluster after 60 minutes of idleness.
sky autostop cluster_name -i 60 --down

sky autostop [OPTIONS] [CLUSTERS]...

Options

--config <config>#

Path to a config file or a single key-value pair. To add multiple key-value pairs add multiple flags (e.g. –config nested.key1=val1 –config nested.key2=val2).

-a, --all#

Autostop all existing clusters.

-u, --all-users#

Autostop all existing clusters for all users.

-i, --idle-minutes <idle_minutes>#

Set the idle minutes before autostopping the cluster. See the doc above for detailed semantics.

--wait-for <wait_for>#

Determines the condition for resetting the idleness timer. This option works in conjunction with --idle-minutes. Options:

1. jobs_and_ssh (default): Wait for in-progress jobs and SSH connections to finish.
2. jobs: Only wait for in-progress jobs.
3. none: Wait for nothing; autostop right after idle-minutes.
Options:

jobs_and_ssh | jobs | none

--cancel#

Cancel any currently active auto{stop,down} setting for the cluster. No-op if there is no active setting.

--down#

Use autodown (tear down the cluster; non-restartable), instead of autostop (restartable).

-y, --yes#

Skip confirmation prompt.

--async, --no-async#

Run the command asynchronously.

Arguments

CLUSTERS#

Optional argument(s)

Jobs CLI#

Cluster jobs CLI#

sky exec#

Execute a task or command on an existing cluster.

If ENTRYPOINT points to a valid YAML file, it is read in as the task specification. Otherwise, it is interpreted as a bash command.

Actions performed by sky exec:

  1. Workdir syncing, if:

    • ENTRYPOINT is a YAML with the workdir field specified; or

    • Flag --workdir=<local_dir> is set.

  2. Executing the specified task’s run commands / the bash command.

sky exec is thus typically faster than sky launch, provided a cluster already exists.

All setup steps (provisioning, setup commands, file mounts syncing) are skipped. If any of those specifications changed, this command will not reflect those changes. To ensure a cluster’s setup is up to date, use sky launch instead.

Execution and scheduling behavior:

  • The task/command will undergo job queue scheduling, respecting any specified resource requirement. It can be executed on any node of the cluster with enough resources.

  • The task/command is run under the workdir (if specified).

  • The task/command is run non-interactively (without a pseudo-terminal or pty), so interactive commands such as htop do not work. Use ssh my_cluster instead.

Typical workflow:

# First command: set up the cluster once.
sky launch -c mycluster app.yaml

# For iterative development, simply execute the task on the launched
# cluster.
sky exec mycluster app.yaml

# Do "sky launch" again if anything other than Task.run is modified:
sky launch -c mycluster app.yaml

# Pass in commands for execution.
sky exec mycluster python train_cpu.py
sky exec mycluster --gpus=V100:1 python train_gpu.py

# Pass environment variables to the task.
sky exec mycluster --env WANDB_API_KEY python train_gpu.py

sky exec [OPTIONS] [CLUSTER] [ENTRYPOINT]...

Options

--config <config>#

Path to a config file or a single key-value pair. To add multiple key-value pairs add multiple flags (e.g. –config nested.key1=val1 –config nested.key2=val2).

-d, --detach-run#

If True, as soon as a job is submitted, return from this call and do not stream execution logs.

-n, --name <name>#

Task name. Overrides the “name” config in the YAML if both are supplied.

--workdir <workdir>#

If specified, sync this dir to the remote working directory, where the task will be invoked. Overrides the “workdir” config in the YAML if both are supplied.

--infra <infra>#

Infrastructure to use. Format: cloud, cloud/region, cloud/region/zone, k8s/context-name, or ssh/node-pool-name. Examples: aws, aws/us-east-1, aws/us-east-1/us-east-1a, aws/*/us-east-1a, k8s/my-context, ssh/my-nodes.

--num-nodes <num_nodes>#

Number of nodes to execute the task on. Overrides the “num_nodes” config in the YAML if both are supplied.

--cpus <cpus>#

Number of vCPUs each instance must have (e.g., --cpus=4 (exactly 4) or --cpus=4+ (at least 4)). This is used to automatically select the instance type.

--memory <memory>#

Amount of memory each instance must have in GB (e.g., --memory=16 (exactly 16GB), --memory=16+ (at least 16GB))

--disk-size <disk_size>#

OS disk size in GBs.

--disk-tier <disk_tier>#

OS disk tier. Could be one of low, medium, high, ultra, best, none. If best is specified, use the best possible disk tier. If none is specified, enforce to use default value and override the option in task YAML. Default: medium

Options:

low | medium | high | ultra | best | none

--network-tier <network_tier>#

Network tier. Could be one of standard, best. If best is specified, use the best network tier available on the specified instance. Default: standard

Options:

standard | best

--use-spot, --no-use-spot#

Whether to request spot instances. If specified, overrides the “resources.use_spot” config.

--image-id <image_id>#

Custom image id for launching the instances. Passing “none” resets the config.

--env-file <env_file>#

Path to a dotenv file with environment variables to set on the remote node.

If any values from --env-file conflict with values set by --env, the --env value will be preferred.

Values from --env-file will also load to secrets with lower preference compared to --secret or --secret-file.

--env <env>#

Environment variable to set on the remote node. It can be specified multiple times. Examples:

1. --env MY_ENV=1: set $MY_ENV on the cluster to be 1.

2. --env MY_ENV2=$HOME: set $MY_ENV2 on the cluster to be the same value of $HOME in the local environment where the CLI command is run.

3. --env MY_ENV3: set $MY_ENV3 on the cluster to be the same value of $MY_ENV3 in the local environment.

--secret-file <secret_file>#

Path to a dotenv file with secret variables to set on the remote node.

If any values from --secret-file conflict with values set by --secret, the --secret value will be preferred.

--secret <secret>#

Secret variable to set on the remote node. These variables will be redacted in logs and YAML outputs for security. It can be specified multiple times. Examples:

1. --secret API_KEY=secret123: set $API_KEY on the cluster to
be secret123.

2. --secret JWT_SECRET: set $JWT_SECRET on the cluster to be the same value of $JWT_SECRET in the local environment.

--local-disk <local_disk>#

Local (instance) storage requirement. Format: [mode:]size[+] or mode. Mode is “nvme” (default) or “ssd”. Size is total GB across all disks. If only mode specified, size defaults to 100+. If only size specified, mode defaults to nvme. Examples:

1. --local-disk nvme:1000+: NVMe SSD with at least 1TB total.

  1. --local-disk ssd:500: SSD with exactly 500GB total.

  2. --local-disk nvme: Any NVMe instance (at least 100GB).

  3. --local-disk 1000+: NVMe (default) with at least 1TB.

Note: Local storage is ephemeral and lost when the instance terminates.

--gpus <gpus>#

Type and number of GPUs to use. Example values: “V100:8”, “V100” (short for a count of 1), or “V100:0.5” (fractional counts are supported by the scheduling framework). If a new cluster is being launched by this command, this is the resources to provision. If an existing cluster is being reused, this is seen as the task demand, which must fit the cluster’s total resources and is used for scheduling the task. Overrides the “accelerators” config in the YAML if both are supplied. Passing “none” resets the config.

-t, --instance-type <instance_type>#

The instance type to use. If specified, overrides the “resources.instance_type” config. Passing “none” resets the config.

--ports <ports>#

Ports to open on the cluster. Accepts a single port (--ports 8080), a range (--ports 8000-8010), or a comma-separated list (--ports 8080,9090). Repeat the flag to specify multiple values (--ports 8080 --ports 9090-9100). If specified, overrides the “ports” config in the YAML.

--async, --no-async#

Run the command asynchronously.

--git-url <git_url>#

Git repository URL.

--git-ref <git_ref>#

Git reference (branch, tag, or commit hash) to use.

Arguments

CLUSTER#

Optional argument

ENTRYPOINT#

Optional argument(s)

sky queue#

Show the job queue for cluster(s).

sky queue [OPTIONS] [CLUSTERS]...

Options

--config <config>#

Path to a config file or a single key-value pair. To add multiple key-value pairs add multiple flags (e.g. –config nested.key1=val1 –config nested.key2=val2).

-u, --all-users#

Show all users’ information in full.

-s, --skip-finished#

Show only pending/running jobs’ information.

-o, --output <output_format>#

Output format. Choices: table, json. Default: table.

Options:

table | json

Arguments

CLUSTERS#

Optional argument(s)

sky cancel#

Cancel job(s).

Example usage: