CLI Rack Management

Updating a Rack

Updating to the latest version

    $ convox rack update
    Updating rack... OK

v3 racks need to be updated through every minor version. We suggest you locate the latest minor rack version that you are updating through and then continuing up versions “step-wise” until you reach your desired version. This is to ensure no internal rack or cluster services fall out of sync/version with each other.

E.g. a rack on Version 3.12.x would need update to the latest 3.13.x version before proceeding to the latest 3.15.x version and so on.

You should always update to the latest patch version of your new version because often times fixes are applied throughout the minor which can cause problems if going to only the base version. Additionally you do not need to be on the highest patch version of your current minor to update your rack to the next minor.

E.g. a rack on Version 3.13.1 should update directly to 3.14.5 (the latest version in 3.14.x at the time of this writing).

Note on Versioning: In the major.minor.patch format, minor versions indicate updates for significant dependencies like Kubernetes, while patch versions introduce feature additions or bug fixes.

Updating to a specific version

    $ convox rack update 3.16.1
    Updating rack... OK

Managing Parameters

Viewing current parameters

    $ convox rack params
    node_disk  20
    node_type  t3.small

Setting parameters

    $ convox rack params set node_disk=30 node_type=c5.large
    Setting parameters... OK

Available Parameters

The parameters available for your Rack depend on the underlying cloud provider.

Amazon Web Services

Name Default
internal_router false
node_capacity_type on_demand
node_disk 20
node_type t3.small
region us-east-1
high_availability * true
proxy_protocol ** false
vpc_id ***
telemetry true

* Parameter cannot be changed after rack creation

** Setting proxy_protocol in an existing rack will require a 5 - 10 minutes downtime window.

*** To avoid CIDR block collision with existing VPC subnets, please add a new CIDR block to your VPC to separate rack resources. Also, remember to pass the internet_gateway_id attached to the VPC. If the VPC doesn’t have an IG attached, the rack installation will create one automatically, which will also be destroyed if you delete the rack.

*** schedule_rack_scale_down and schedule_rack_scale_up are mutually exclusive. So you have to set both of them properly for the scheduled timed off. If you set only schedule_rack_scale_down, it will not scale up on its own.


Digital Ocean

Name Default
node_type s-2vcpu-4gb
region nyc3
registry_disk 50Gi
high_availability * true
telemetry true

* Parameter cannot be changed after rack creation


Google Cloud

Name Default
node_type n1-standard-1
telemetry true


Microsoft Azure

Name Default
node_type Standard_D3_v3
region eastus
telemetry true