Cloud 66 Toolbelt Commands

These commands are listed alphabetically by top level command name.

backups list

Lists all the managed backups of an application grouped by their database type and/or backup schedule.

$ cx backups list --stack <application name> --latest 

$ cx backups list -s "My Awesome App" --dbtypes mysql --latest

backups download

Download a managed database backup via the command line. If the backup spans multiple files, the command will automatically concatenate them into a single file.

$ cx backups download --stack <application name> [--download <download directory>] <backup id>

$ cx backups download -s mystack -d /tmp/backups 23212

Note

backups new

Creates a new database backup task for an application.

cx backups new --stack <application name> --dbtypes postgresql --frequency <schedule> --gzip <bool> --exclude-tables <table name> --run-on-replica <bool> --backup-type <type>

$ cx backups new -s mystack	--dbtypes postgresql --frequency="0 */1 * * *" --gzip true --exclude-tables my_log_table --run-on-replica false --backup-type text

Note

config

Allows you to configure multiple profiles in cx to support multiple Cloud 66 accounts. Please read our separate guide on configuring Toolbelt.

containers list

Alias: container list

Lists all the containers running on an application or server (depending on your parameters).

$ cx containers list --stack <application name> [--server <server name>][--enviornment <environment name>][--verbose]

$ cx containers list -s mystack
$ cx containers list -s mystack --server orca
$ cx containers list -s mystack --verbose --server orca

containers attach

Alias: container attach

Attach to a container on the given stack by container ID.

$ cx containers attach --stack <application name> <container ID>

$ cx containers attach -s mp-app 2844142c

containers stop

Alias: container stop

Stops a specific container on a given stack by container ID or name (supports partial IDs and names).

$ cx containers stop --stack <application name> <container ID>|<container name>

$ cx containers stop -s mystack 2844142cbfc064123777b6be765b3914e43a9e083
$ cx containers stop -s mystack 2844142c
$ cx containers stop -s mystack web.pro-active-quick-witted-dinosaur
$ cx containers stop -s mystack web

containers restart

Alias: container restart

Restarts a particular container on a given stack by container ID or name (supports partial IDs and names).

$ cx containers restart --stack <application name> <container ID>|<container name>

$ cx containers restart -s mystack 2844142cbfc064123777b6be765b3914e43a9e083afce4e4348b5979127c220c
$ cx containers restart -s mystack 2844142c
$ cx containers restart -s mystack web.pro-active-quick-witted-dinosaur
$ cx containers restart -s mystack web

databases promote-slave

Alias: database promote-slave

Promotes the specified slave database server to a standalone master. The slave will be reconfigured as the new standalone DB. Providing the database type is optional and is only necessary for shared servers where we can’t automatically determine the target database type.

The existing master and other slaves will need to be removed after this process as after this the new configuration will have only a single database. You will be able to configure replication again by scaling up new servers.

In the case of any servers not being accessible during this time, those servers will remain unchanged. It is therefore important to stop/shut down those servers in this case (or to manually stop the DB service on those servers) as having multiple masters in a cluster could cause problems throughout the cluster.

$ cx databases promote-slave --stack <stack name> [--dbtype <database type>] <slave server name>

$ cx databases promote-slave -s My_Awesome_App my_redis_replication_slave
$ cx databases promote-slave --stack My_Awesome_App --dbtype=mysql my_slave_server_name

databases resync-slave

Alias: database resync-slave

Re-syncs the specified slave database server with its master database server. From time-to-time your slave database may go out of sync with its master. This action attempts to re-sync your specified slave server. This can happen depending on many factors (such as DB size, frequency of change, networking between servers etc).

The server provided must have already been configured as a replication slave via the Cloud 66 UI. Providing the database type is optional and is only necessary for shared servers where we can’t automatically determine the target database type.

$ cx databases resync-slave --stack <application name> --dbtype <database type> <slave server name>

$ cx databases resync-slave -s My_Awesome_App my_slave_server_name
$ cx databases resync-slave -s My_Awesome_App --dbtype=postgresql my_slave_server_name

download

Use this command to download a copy of file from the remote server to your local computer. If you don’t specify a target directory, the file will be downloaded to your current local directory.

$ cx download --stack <application name> --server <server name> <path to source file> [<target directory>]

$ cx download -s "My Awesome App" --server web /tmp/file.txt /tmp/file.txt

dump-token

Prints the content of the cx token file with no new lines.

Usage

$ cx dump-token

env-vars list

Prints environment variables (both keys and values) for your application to terminal. If environment variable keys are specified, the list will be limited to those keys. The --history option lists any recent changes to each variable.

$ cx env-vars list --stack <application name> <environment variables> [--history]

$ cx env-vars list -s mystack
$ cx env-vars list -s mystack RAILS_ENV
$ cx env-vars list -s mystack RAILS_ENV ANOTHER_VARIABLE --history

env-vars download

Downloads the environment variables from an application and writes them to a file. This file can either use the same format as web download (dotenv) or json.

You can specify which kinds of variables to download using environment-type with the following variables: 

• all returns all environment variables
• user returns user-created environment variables
• generated returns environment variables generated by Cloud 66
• locked returns non-editable environment variables that were generated by Cloud 66

$ cx env-vars download --stack <application name> --environment-type <type> --file <filename> --file-type <file-type>

$ cx env-vars download -s mystack --file environment_variables_json --file-type json
$ cx env-vars download -s another_app --file environment_variables_dotenv --file-type dotenv

env-vars set

Adds (or updates) a single environment variables for your application. You can use the --apply-strategy option to specify when Cloud 66 will apply the change in environment variables to your servers. The default is immediately.

$ cx env-vars set --stack <application name> [--apply-strategy] <key> <value> 

$ cx env-vars set -s mystack FIRST_VAR=123
$ cx env-vars set -s mystack SECOND_VAR='this value has spaces in it'
$ cx env-vars set -s mystack --apply-strategy immediately THIRD_VAR='value-applied-now'
$ cx env-vars set -s mystack --apply-strategy deployment FOURTH_VAR='value-after-deployment'

env-vars upload

Set the environment variables for an application based on a file in either dotenv or json format.

You must specify an apply-strategy for your upload process. They can either be applied immediately or on the next deployment.

$ cx env-vars upload --stack <application name> --file <filename> --file-type <type> [--apply-strategy <strategy>] [--delete]

$ cx env-vars upload -s mystack --file environment_variables_dotenv --file-type dotenv --apply-strategy deployment --delete
$ cx env-vars upload -s my_other_stack --file environment_variables_json --file-type json --apply-strategy immediately

failover-groups list

Lists the Failover Groups for a Cloud 66 account. Info includes the Failover Group ID, address, attached applications and current active application.

$ cx failover-groups list [--output <view>]

$ cx failover-groups list -o wide

failover-groups add

Adds a new Failover Group to a Cloud 66 account. You can create an empty Failover Group with neither primary nor secondary app set.

$ cx failover-group add [--primary <primary app>] [--secondary <secondary app>] [--current <current app>] [--no-primary] [--no-secondary]

$ cx failover-group add -p my-main-app -s my-backup-app

failover-groups delete

Deletes an existing Failover Group from a Cloud 66 account.

$ cx failover-groups delete --uid <failover UID>

$ cx failover-groups delete --uid "5999b763474b0eafa5fafb64bff0ba80"

failover-groups update

Updates an existing Failover Group on a Cloud 66 account.

$ cx failover-group update --uid <failover UID> [--primary <primary app>] [--secondary <secondary app>] [--current <app pointer>] [--no-primary] [--no-secondary]

$ cx failover-group update --uid "5999b763474b0eafa5fafb64bff0ba80" -p my-main-app -s my-backup-app --current 2

formations list

Alias: formation list

List all the formations of a stack in a Skycap application by name and UID.

$ cx formations list --stack <application name> <formation names>

$ cx formations list -s mystack foo bar # only show formations "foo" and "bar"

formations commit

Alias: formation commit

Commits the specified stencil(s) to the application’s template repository with a commit message.

$ cx formations commit --stack <application name> -f <formation name> --stencil <stencil name> | --dir <directory path> --message <your commit message> [--default-folders]

$ cx formations commit -s my-skycap-app -f main-formation --stencil app-template-1 --message "updates to structure"
$ cx formations commit -s my-skycap-app --formation main-formation --dir stencils_for_editing --message "edited variables"

formations create

Alias: formation create

Creates a new Formation in the specified Skycap application.

$ cx formations create --stack <application name>] --name <formation name> --template-repo <template repo URL> --template-branch <branch name> [--tags <tagA> <tagB>] 

$ formations create -s my-skycap-app --name new-formation --template-repo "https://my.repo.url/skycap-stencils" --template-branch "main" --tags ver2

formations deploy

Alias: formation deploy

Deploys a Formation in a Skycap application.

$ cx formations deploy --stack <application name> -f <formation name> [--snapshot-uid <UID>] [--use-latest <boolean>] [-w <workflow name>]

$ formations deploy -s my-skycap-app -f main-formation  --use-latest true -w quick-workflow

formations fetch

Alias: formation fetch

Fetches all stencils from a Formation in a Skycap application and downloads them to a local directory.

$ cx formations fetch --stack <application name> -f <formation name> [--outdir <directory path>] [--overwrite <bool>]

$ formations fetch -s my-skycap-app -f main-formation --outdir "~/my-formations" --overwrite true

formations stencils list

Alias: formation stencils list

List all the stencils in a formation.

$ cx formations stencils list --formation <formation name> --output <view>

$ cx formations stencils list --formation foo 
$ cx formations stencils list --formation bar --output wide

gateways list

Lists all the gateway servers attached to a Cloud 66 account or organization.

$ cx --org <organization_name> gateways list [--verbose]

$ cx --org my-compay gateways list --verbose

gateways add

Add a gateway server to a Cloud 66 account.

$ cx gateways add --name <gateway name> --address <gateway address> --username <gateway username> --private-ip <private ip of gateway>

$ cx gateways add --name aws_bastion --address 192.168.100.100  --username ec2-user  --private-ip 192.168.1.1
$ cx --org My_Awesome_org gateways add --name aws_bastion --address 1.1.1.1  --username ec2-user  --private-ip 192.168.2.2

gateways close

Close a gateway (prevents traffic flowing via the gateway).

$ cx gateways close --name <gateway name>

$ cx gateways close --name aws_bastion

gateways open

Opens a gateway for use with Cloud 66 for a specified amount of time (TTL).

$ cx gateways open --name <gateway name> --key <path/to/gateway/key/file>  --ttl <time to live>

$ cx gateways open aws_bastion --key /tmp/gateway.pem --ttl 45m

gateways remove

Remove a gateway from a Cloud 66 account.

$ cx gateways remove --name <gateway name>

$ cx gateways remove --name aws_bastion

help

Shows a full list of commands or detailed help for one command.

Usage

$ cx help
$ cx <command> --help

info

Shows information about your account, toolbelt and the specified stack or the current directory.

$ cx info --stack <application name --unmanaged

$ cx info -s my-application --unmanaged

init

Initializes the Toolbelt. Please read our separate guide on installing and configuring Toolbelt.

init agent

Initializes the Toolbelt as a standalone (headless) agent. Please read our separate guide on installing and configuring Toolbelt.

jobs list

Alias: job list

Lists all automated (scheduled) jobs on an application or a server.

$ cx jobs list --stack <application name> --server <server name>|<server ip>|<server role> --service <service name>

$ cx jobs list -s my-app
$ cx jobs list -s my-app --server orca
$ cx jobs list -s my-app --server 168.123.448.56 --service web
$ cx jobs list -s my-app --service web

jobs run

Alias: job run

Runs the given job once with the given parameters.

$ cx jobs run --stack <application name> --arg [--arg option --arg option] <job name>

$ cx job run -s "My Awesome App" my_job
$ cx job run -s "My Awesome App" --arg "arg1" --arg "arg2" my_job

lease

This will open the firewall of the given server for a limited time. ‘Time to open’ is in minutes. By default the firewall closes after 20 minutes. The maximum time to open is 240 minutes.

$ cx lease --stack <application name> --port <port to open> [--from <from IP>] --tto <lease time>

$ cx lease -s mystack
$ cx lease -s mystack -t 120 -p 3306
$ cx lease -s mystack -p 3306 -f 52.65.34.98

login

Opens the default web browser and logs into the associated Cloud 66 account. This makes it easier to login to Cloud 66 web UI by streamlining your login through a registered and authenticated Toolbelt.

Usage

$ cx login

notifications download

Download all the alert settings for a given application as a YAML formatted file.

$ cx notifications download --stack <application name> --file <filename>

$ cx notifications download -s my-stack --file my-stack-alerts.yml

notifications upload

Uploads notifications in a YAML formatted file. Settings in the file will replace any existing settings. If an application group is specified, all of the apps in the group will be updated.

$ cx notifications upload [--stack <application name> | --application-group <group name>] --file <filename>

$ cx notifications upload -a production-group -f my-notification-settings.yml

open

Opens the default web browser and opens the web end-point of a given application.

$ cx open --stack <application name> <server name>

$ cx open lion
$ cx open -s mystack
$ cx open -s mystack lion

processes list

Alias: process list

List the details of the processes running on an application or a server.

$ cx processes list --stack <application name> [--server <server name>] [--name <process name>]

$ cx processes list -s mystack
$ cx processes list -s mystack --server orca
$ cx processes list -s mystack --name worker
$ cx processes list -s mystack --server orca --name worker

processes pause

Alias: process pause

Pauses all processes for the given service and/or server.

$ cx processes pause --stack <application name> [--server <server name>] [<process name>]

$ cx processes pause -s mystack a_backend_process
$ cx processes pause -s mystack --server my_server
$ cx processes pause -s mystack --server my_server a_backend_process

processes restart

Alias: process restart

Restarts all processes on the given service and/or server.

$ cx processes restart --stack <application name> [--server <server name>] [<process name>]

$ cx processes restart -s mystack a_backend_process
$ cx processes restart -s mystack --server my_server
$ cx processes restart -s mystack --server my_server a_backend_process

processes resume

Alias: process resume

Resumes all paused processes on the given service and/or server.

$ cx processes resume --stack <application name> [--server <server name>] <process name>

$ cx processes resume -s mystack a_backend_process
$ cx processes resume -s mystack --server my_server
$ cx processes resume -s mystack --server my_server a_backend_process

processes scale

Alias: process scale

Starts <count> processes from the given process definition. <count> can be an absolute value like 2 or a relative value like [+2] or [-3] If server is provided, will start <count> processes on that server. If server is not provided, will start <count> processes on every server. NOTE: the square brackets are required for relative count values.

$ cx processes scale --stack <application name> [--server <server name>] [--name <process name>] [<count>]

$ cx processes scale -s mystack --server backend1 --name worker [+5]
$ cx processes scale -s mystack --server backend2 --name worker [-5]
$ cx processes scale -s mystack --server backend3 --name worker 15
$ cx processes scale -s mystack --name worker 2

redeploy

Alias: stacks redeploy

Enqueues redeployment of an existing application. If the app is already building, another build will be enqueued and performed immediately after the current one is finished.

$ cx redeploy --stack <application name> --listen [-y] [--git-ref <git_ref>] [--service <service>] [--deploy-strategy <strategy>] [--rollout-strategy <strategy>] [--canary-percentage <percentage>] [--deployment-profile <profile name>]

$ cx redeploy -s "My Awesome App" -e production --deploy-strategy fast
$ cx redeploy -s "My Awesome App" -e production -y --git-ref my_git_ref_value
$ cx redeploy -s "My Awesome Containerized App" --service web:8c7f3d393162f88b8b9493f6babec574b03ca957 --service api:latest

register-server

A shortcut to run the server registration script on a group of servers.

$ cx register-server [--org <organization>] [--server <IP address>] [--file <filename.txt>] [--user <username>] [--key <private SSH key>] [--force-local-ip <bool>] [--tags <tagA,tagB>]

$ cx register-server --org team --user root --server 149.56.134.22 --key ~/.ssh/private_key
$ cx register-server --org team --user ubuntu --file servers.txt --key ~/.ssh/private_key
$ cx register-server --org team --user ubuntu --file servers.txt --key ~/.ssh/private_key --force-local-ip true
$ cx register-server --org team --user ubuntu --file servers.txt --key ~/.ssh/private_key --tags "dc 1,az2"

run

Execute a command directly on a remote server, in a service, or in a existing container. To do this it:

1. Opens the firewall for SSH from your IP address temporarily (20 minutes)
2. Downloads your SSH key if you don’t have it
3. Starts a SSH session
4. Executes the command specified and returns its output.

You need to have the correct access permissions to use this command. You can use either the server name (e.g. lion) or the server IP (e.g. 123.123.123.123) or the server role (e.g. web). If a role is specified the command will connect to the first server with that role.

This command is only supported on Linux and OS X clients (for Windows you can run this in a virtual machine if necessary)

$ cx run --stack <application name> [--server <server name> | <IP address>] [--service <service name>] [--container <container name>] [--interactive] '<commands>'

$ cx run -s mystack --server lion 'ls -la'
$ cx run -s mystack --server lion -i
$ cx run -s mystack --svc webapp 'ls -la'
$ cx run -s mystack --service api --interactive 'bundle exec rails c'
$ cx run -s mystack --container web-123 -i 'bundle exec rails c'

servers list

Alias: server list

List details for all the servers used by an application including name, IP address, server role and the date/time it was created. The <name> argument can be a list of server names entered as separate parameters.

$ cx servers list --stack <application name> <server name>

$ cx servers list -s mystack
orca         162.243.201.164  [rails web app]  Healthy   Mar 26 11:23
snowleopard  107.170.98.160   [mysql db]       Building  Mar 26 11:23
$ cx servers list -s mystack orca
orca         162.243.201.164  [rails web app]  Healthy   Mar 26 11:23

servers reboot

Alias: server reboot

Reboot a specific server.

$ cx servers reboot --stack <application name> --server <server name>

$ cx server reboot --stack my-app --server lion

servers settings list

Alias: server settings list

Lists all the settings applicable to the given server. It also shows the key, value and the readonly flag for each setting. Settings can be a list of multiple arguments. To change each server setting, use the server-set command.

$ cx servers settings list --stack <application name> --server <server name> <setting>

$ cx servers settings list -s mystack --server lion
server.name lion readonly
disk.space.alert.threshold  80  read/write

$ cx servers settings list -s mystack --server db server.name
server.name tiger readonly

services info

Alias: service info

Get info for given the service. The list of available services can be obtained through the services list command. If the server is provided it will only query the specified server.

$ cx services info --stack <application name> [--server <server name>] <service name> 

$ cx services info -s mystack my_web_service
$ cx services info -s mystack a_backend_service
$ cx services info -s mystack --server my_server my_web_service

services list

Alias: service list

List all the services and running containers of a whole application or a specific server.

$ cx services list --stack <application name> [--server <server name>] [<service name>]

$ cx services list -s mystack
$ cx services list -s mystack --server orca
$ cx services list -s mystack --server orca --service web
$ cx services list -s mystack --service web

services pause

Alias: service pause

Pauses all the containers for the given service. The list of available services can be obtained through the list services command. If is provided it will query only the specified server.

$ cx services pause --stack <application name> [--server <server name>] <service name>

$ cx services pause -s mystack my_web_service
$ cx services pause -s mystack a_backend_service
$ cx services pause -s mystack --server my_server my_web_service

services restart

Alias: service restart

Restarts all the containers for the given service. The list of available services can be obtained through the list services command. If is provided it will query only the specified server.

$ cx services restart --stack <application name> [--server <server name>] <service name>

$ cx services restart -s mystack my_web_service
$ cx services restart -s mystack a_backend_service
$ cx services restart -s mystack --server my_server my_web_service

services resume

Alias: service resume

Resumes all the containers from the given service that were previously paused. The list of available services can be obtained through the list services command. If is provided it will query only the specified server.

$ cx services resume --stack <application name> [--server <server name>] <service name>

$ cx services resume -s mystack my_web_service
$ cx services resume -s mystack a_backend_service
$ cx services resume -s mystack --server my_server my_web_service

services scale

Alias: service scale

Starts <count> containers for the given service across the stack. If <count> is an absolute value like 2, then that will be the total of <count> containers across the application. If <count> is a relative value like [+2] or [-3], then the current total count of containers across the application will be changed by <count>. NOTE: the square brackets are required for relative count values.

$ cx services scale --stack <application name> <service name> <count>

$ cx services scale -s mystack my_web_service 1
$ cx services scale -s mystack a_backend_service [+5]
$ cx services scale -s mystack a_backend_service [-2]

services stop

Alias: service stop

Stops all the containers for the given service. The list of available services can be obtained through the list services command. If <server name> is provided it will query only the specified server.

$ cx services stop --stack <application name> [--server <server name>] <service name>

$ cx services stop -s mystack my_web_service
$ cx services stop -s mystack a_backend_service
$ cx services stop -s mystack --server my_server my_web_service

settings list

Alias: setting list

Lists all the settings for the given application, including the key, value and readonly flag for each setting. You can use <setting> multiples times to query multiple services.

$ cx settings list --stack <application name> <setting>

$ cx settings list -s mystack
stack.name mystack readonly
git.branch master read/write
git.repository git://git@github.com:cloud66-samples/rails.git  read/write

$ cx settings list -s mystack git.branch
git.branch master read/write

settings set

Alias: setting set

Sets and applies the value of a setting to an application.

$ cx settings set --stack <application name> <setting> <values>

$ cx settings set -s mystack git.branch dev
$ cx settings set -s mystack allowed.web.source 191.203.12.10
$ cx settings set -s mystack allowed.web.source anywhere
$ cx settings set -s mystack maintenance.mode  1|true|on|enable
$ cx settings set -s mystack maintenance.mode  0|false|off|disable

Available settings

skycap listen

Polls your Skycap application and prints workflow events when they are triggered, effectively running the commands embedded in the workflow on the client machine.

$ cx skycap listen --stack <application name> [--log-level <level>] [--interval <time>]

$ cx skycap list --stack my-skycap-app --log-level "info" --interval "10s"

snapshots list

Lists details of the snapshots in a Skycap application, including triggers, snapshot UUID and date/time

$ cx snapshots list --stack <application name>

$ cx snapshots list -s mystack

snapshots render

Renders the requested files for the given formation and snapshot

$ snapshots render --stack <application name> --formation <formation UID> --snapshot <snapshot UID> [--latest] [--files <file name>] [--outdir <directory path>] [--filter <filter name>] [--ignore warnings]

$ cx snapshots render -s mystack --formation fm-xxxx --snapshot sn-yyyy --latest --files foo.yaml --files bar.yml --ignore-warnings

ssh

Allows direct SSH shell into your servers by opening the firewall temporarily for the source IP address, downloading the SSH key and starting a SSH session with one command.

Your server SSH key is downloaded to ~/.ssh and re-used in subsequent SSH connections via the toolbelt. You need to have shell to server rights over the application to use this command.

If your server deployed behind a gateway, you need to provide the private key in order to pass through the gateway.

$ cx ssh  [--gateway-key <path to gateway key>] --stack <application name> <server name>|<server ip>|<server role> --vv

$ cx ssh -s mystack lion
$ cx ssh -s mystack 52.65.34.98
$ cx ssh -s mystack web
$ cx ssh --gateway-key ~/.ssh/bastion_key  -s mystack db

stacks clear-caches

Alias: stack clear-caches

For improved performance, Cloud 66 caches volatile code. It is possible for a those caches to become invalid if you switch branches, change git repository URL, rebase or force a commit. Since switching branch or changing git repository URL is done via the Cloud 66 interface, your volatile caches will automatically be purged. However, rebasing or forcing a commit is external to Cloud 66 and therefore doesn’t trigger the purge, so this command can be used to manually purge the existing volatile caches.

$ cx stacks clear-caches --stack <application name>

$ cx stacks clear-caches -s "my updated app"

stacks configure download

Alias: stack configure download

Download configuration files such as a service.yml or manifest.yml. (Maestro only)

$ cx stacks configure download --file <filename> --stack <application name> --output <output path>

$ cx stacks configure download -f service.yml -s myapp -o /c66/config-files/service.yml

stacks configure list-versions

Alias: stack configure list-versions

List the versions of configuration files such as a service.yml or manifest.yml. (Maestro only)

$ cx stacks configure list-versions --file <filename> --stack <application name> --version <file version type>

$ cx stacks configure list-versions -o service.yml -s myapp

stacks configure upload

Alias: stack configure upload

Upload configuration files such as a service.yml or manifest.yml. (Maestro only)

$ cx stacks configure upload --file <filename> --stack <application name> --comments <comment>

$ cx stacks configure upload -f service.yml -s myapp -c "updates to ports"

stacks configuration list

Alias: stack configuration list

List all the available configurations on an application.

$ cx stacks configuration list --stack <application name>

$ cx stacks configuration list -s my-app

stacks configuration apply

Alias: stack configuration apply

Applies the latest configuration to an application. You can find all the types of configuration available on your application using the stacks configuration list function.

$ cx stacks configuration apply --stack <application name> --type <config type>

$ cx stacks configuration apply -s my-application -t nginx

stacks configuration download

Alias: stack configuration download

Gets the content of the specified configuration file from the given application and either prints it to screen or saves it as a file. You can find all the types of configuration available on your application using the stacks configuration list function.

$ cx stacks configuration download --stack <application name> --type <config type> --output <filename>

$ cx stacks configuration download -s my-application -t nginx -o nginx.conf

stacks configuration upload

Alias: stack configuration upload

Updates the content of the specified configuration type on the stack and (optionally) applies it. You can find all the types of configuration available on your application using the stacks configuration list function.

$ cx stacks configuration upload --stack <application name> --type <config type> --source <source file> --no-apply --commit-message <message>

$ cx stacks configuration upload -s my-app -t nginx --source nginx.conf --no-apply --commit-message "changes to error pages"

stacks list

Alias: stack list

Lists applications. Shows the application name, environment, and last deploy time. You can query (multiple) applications by name - but the command will display all applications by default.

$ cx stacks list [<application name>] [--output <output style>]

$ cx stacks list
		mystack     production   Jan 2 12:34
		mystack     staging      Feb 2 12:34
		mystack-2   development  Jan 2 12:35

$ cx stacks list mystack-2
		mystack-2   development  Jan 2 12:34

stacks create

Alias: stack create

Creates a new Maestro application based on a service definition (service.yml) and an optional application Manifest (manifest.yml).

$ cx stacks create --name <new application name> --service_yaml <service definition>

$ cx stacks create --name my_maestro_stack --service_yaml service.yml --manifest_yaml manifest.yml

stacks listen

Alias: stack listen

Acts like a tail for all the deployment logs for an application (to tail a specific log file, see the function below).

$ cx stacks listen --stack <application name>

$ cx stacks listen -s my-app

stacks reboot

Alias: stack reboot

Reboots groups of servers in your application. Valid values for the <group> argument are all, web, haproxy, and db. Database specific values like mysql or redis are also supported.

<strategy> specifies whether you want your web servers to be rebooted in parallel or in serial. For serial reboots web servers are removed and re-added to the load balancer one by one. Non-web server will always be rebooted in parallel. If this value is left unspecified, Cloud 66 will determine the best strategy based on your infrastructure layout.

$ cx stacks reboot --stack <application name> --group <server group> --strategy <reboot strategy> -y

$ cx stacks reboot -s mystack
$ cx stacks reboot -s mystack --group web
$ cx stacks reboot -s mystack --group all -y
$ cx stacks reboot -s mystack --strategy parallel
$ cx stacks reboot -s mystack --group web --strategy serial -y

stacks redeploy

Alias: stack redeploy

Triggers the deployment of an application. Alias of redeploy function.

stacks restart

Alias: stack restart

Sends a restart signal to all application components. This means different things for different components. For a web server, it means a restart of nginx. For an application server, this might be a restart of the worker processes.

$ cx stacks restart --stack <application name>

$ cx stacks restart -s my-app

stacks ssl

Alias: stack ssl

Add an SSL certificate to a stack.

$ cx stacks ssl --stack <application name> --type <certificate type> --domain <domain name> --ssl-termination --cert <certificate file> --key <SSL key file> --intermediate <intermediate cert file> --overwrite

$ cx stacks ssl add -s my-stack --type lets_encrypt --domain 'web.domain.com' --domain 'api.domain.com' --overwrite

$ cx stacks ssl add -s my-stack --type manual --cert /certs/my_certificate --key /ssl/my_key --intermediate /certs/my_intermediate_cert

tags add

Add tags to a given entity.

$ cx tags add --entity <entity type> --id <entity ID> --tags <tag>

$ cx tags add --entity stack --id 12 --tags foo --tags bar

tags delete

Remove tags from a given entity.

$ cx tags delete --entity <entity type> --id <entity ID> --tags <tag>

$ cx tags delete --entity stack --id 45 --tags buzz --tags fuzz

tail

Runs a Linux tail command on the specified server and given log file. You must specify the log file name including the extension. If you don’t specify a path, or specify a relative path, then we will assume <stack-directory>/current/log (i.e. the subdirectory und $STACK_PATH) as the current directory. You can specify a different (absolute) log path as needed.

This command is only supported on Linux and OS X.

$ cx tail --stack <application name> <server name> | <server ip> | <server role> /optional/log/path/<log filename>

$ cx tail -s mystack production.log
$ cx tail -s mystack 52.65.34.98 nginx_error.log
$ cx tail -s mystack web /custom/logs/my.log

templates list

Lists all stencil template repositories for Skycap applications in an account.

Usage:

$ cx templates list

templates resync

Pulls the latest code from the stencil template repository for a specific template.

$ cx templates resync --template <template UID>

$ cx templates resync --template 'bt-2e0810a17c33ab35d7970ff330b1f916'

templates show

Shows a single template repository and its stencils.

$ cx templates show --name <repo name>

$ cx templates show --name 'my repo'

test

Checks if cx is properly installed and authenticated.

Usage:

$ cx test

tunnel

Opens an SSH tunnel between your local machine and the remote server on a specific port. This is useful when connecting to remote databases or other services using local tools.

tunnel does the following:

1. Opens a lease in port 22 for your local IP address
2. Fetches your SSH key from your Cloud 66 account
3. Starts an SSH tunnel between your machine and the server on the given ports
4. Closes the tunnel when you exit the Toolbelt (Ctrl-C)

Applications using gateways (Bastion servers) are not supported.

If a role is specified the command will connect to the first server with that role.

To specify the ports for the tunnel, use --local and --remote arguments. For example, if you need to connect to a MySQL server, you can use 3307 locally and 3306 (MySQL port on the server) as the remote port. Once the tunnel is established, you can use your favourite MySQL client to connect to the server on 127.0.0.1 and the local port (3307 in this case).

If a local port is not specified, cx will use “remote + 1” as a convention for the local port. For example, if you only specify --remote 5432 without explicitly specifying local, cx will use 5433 as the local port.

This command is only supported on Linux and OS X (for Windows you can run this in a virtual machine if necessary)

$ cx tunnel --stack <application name> --server <server name> | <server IP> | <server role> --local <local port> --remote <remote port>

$ cx tunnel -s mystack --server lion --local 3307 --remote 3306
$ cx tunnel -s mystack --server 52.65.34.98 --local 3307 --remote 3306
$ cx tunnel -s mystack --server web -l 3307 -r 3306

update

This command runs automatically. You should not need to run it manually. You can use it to force cx to use a certain version.

Usage:

$ cx update --force <version>

upload

Copies a file from your local computer to the remote server. Uploads the files to the /tmp directory by default, unless a path is specified.

This command open the firewall for SSH from your IP address temporarily (20 minutes), downloads the keys if you don’t have them and starts a SSH session. If a role is specified the command will connect to the first server with that role.

This command is only supported on Linux and OS X (for Windows you can run this in a virtual machine if necessary)

$ cx upload --stack <application name> --server <server name> | <server IP> | <server role> /path/to/source/file /path/to/target/directory

$ cx upload -s mystack --server lion /tmp/file.txt
$ cx upload -s mystack --server lion /mydir/files/file.txt /var/www/app
$ cx upload -s mystack --server 52.65.34.98 /user/archives/yes.zip
$ cx upload -s mystack --server web /path/to/source/file /path/to/target/directory

users list

Shows a list of all the users in an organization that you have rights to manage. You can find your <organization name> by using cx info.

$ cx --org <organization name> users list

$ cx --org my-org users list

users apply-profile

Apply Profile allows you to apply a user’s Access Profile to another one. To use this command you need to have an Access Profile as a json file. This can be generated using the users show command with the json option. Once you have the file you can modify it to make any changes you require in the Access Profile.

Any missing attribute for the json Access Profile will be left unchanged even if override is used. Also, override doesn’t have any effect on the contents of the account_profile section.

$ cx users apply-profile <user email> --json <access profile>

$ cx --org My_Awesome_org users apply-profile jack@gmail.com --json /tmp/jim_profile.json
$ cx --org My_Awesome_org users apply-profile jack@gmail.com --json /tmp/jim_profile.json --override

users show

Returns details about a user. You can dump these as a json file for use with the users apply-profile function.

$ cx users show <user email> --json <filename>

$ cx users show jim@gmail.com --json /tmp/jim_profile.json

Need help with deployments?

Contact Support

More Questions?

Join the Slack Channel