Introduction to the cf command line

anynines_cheat_sheetThis article is intended for developers new to anynines and Cloud Foundry. We will walk through the typical steps to deploy an application to anynines. You will learn how to use the cf command line tools to interact with the anynines servers.


We assume that you already registered with and downloaded and installed the cf CLI tools from here.


We created a simple example application for demonstration purposes. Please have a look at it here. It is a small, standard Rails app using ActiveRecord with a MySQL backend.

Let’s clone the application to our local machine:

[bash light=”true”]$> git clone[/bash]

As we want to dive deeper into the cf command line, we won’t use a deployment manifest in this tutorial. For more information on deployment manifests please refer to our article dedicated to that topic.


Before deploying applications to anynines we need to choose the cloud’s API endpoint and login using our anynines user credentials:

[bash light=”false”]$> cf api

<pre>$> cf login

API endpoint:


Password> ********



Targeted org user_example_com

Targeted space production

API endpoint: (API version: 2.6.0)

Org:          user_example_com
Space:        production

Now we are logged in and targeting our production space.

Space management

As this is only a pet app we wouldn’t want to deploy to our production space directly. So let’s create a new space called “playground” to deploy our experiments to:

[bash light=”false”]$> cf create-space playground

Creating space playground in org user_example_com as…


Assigning role SpaceManager to user in org user_example_com / space playground as…


Assigning role SpaceDeveloper to user in org user_example_com / space playground as…


TIP: Use ‘cf target -o user_example_com -s playground’ to target new space

As the tip suggests, we switch the space to our playground environment by using the cf target command:

[bash light=”true”]$> cf target -o user_example_com -s playground[/bash]

Service Creation

As we need a MySQL service instance for our demo application let’s have a look at the available plans:

[bash light=”false”]$> cf marketplace

Getting services from marketplace in org user_example_com / space playground as…


service         plans                             description

elasticsearch   Pluto-free                        Elasticsearch search service

mongodb         100, Venus-20, Mercury-5          MongoDB NoSQL database

mysql           Mercury-5, Pluto-free, Venus-20   MySQL database

postgresql      Mercury-5, Venus-20, Pluto-free   PostgreSQL database (vFabric)

rabbitmq        100, Venus-2                      RabbitMQ message queue

redis           100, Venus-2                      Redis key-value store

swift           free                              Swift service


Let’s create a MySQL service instance using the Pluto-free plan:

[bash light=”false”]$> cf create-service mysql Pluto-free mysql-demo-instance

Creating service mysql-demo-instance in org user_example_com / space playground as…



We can list the service instances in the current space using the following command:

[bash light=”false”] $> cf services

Getting services in org user_example_com / space playground as…


name                  service   plan         bound apps

mysql-demo-instance   mysql     Pluto-free


As our service instance is ready, we can now proceed with our application deployment.

Application Deployment

Use the cf push command for deploying applications. You can view a list of available options by using the –help option:

[bash light=”true”]$> cf push –help [/bash]

Let’s push our application to the servers:

[bash light=”false”]$> cf push mydemoapp -b ‘’ -c ‘bundle exec rake db:migrate; bundle exec rails s -p $PORT’ -d -i 1 -m 512M -n mydemoapp –no-start

Creating app mydemoapp in org user_example_com / space playground as…


Creating route…


Binding to mydemoapp…


Uploading mydemoapp…

Uploading app files from: /Users/dude/Documents/rubydev/anynines/test_apps/ruby/simple_rails_app

Uploading 25.4K, 193 files



A short command explanation:

-b : specify the buildpack to use for configuring our application

-c : specify the start command for our application

-d : specify the domain to use for our application

-i : sets the number of instances for running our application

-m : sets the maximum RAM usage for our application

-n : sets the subdomain under which our application will be available

–no-start : don’t start the application immediately

We added the –no-start option since we did not connect our freshly created service with our application. We will do this in the next section.

Service Binding

A Service Binding represents a connection between an application and a service. The service connection information and credentials will be made available to the application via the VCAP_SERVICES environment variable. For more information on Service Bindings and usage please refer to our documentation.

We can create a binding like this:

[bash light=”false”]$> cf bind-service mydemoapp mysql-demo-instance

Binding service mysql-demo-instance to app mydemoapp in org user_example_com / space playground as…


Now our application can read the connection and credential data needed to connect to our demo service. In this special case the buildpack will automatically create a database.yml file for us, so we don’t have manually adjust our application.

Application startup

Let’s start our application:

[bash light=”false”]$> cf start mydemoapp

Starting app mydemoapp in org user_example_com / space playground as…


Cloning into ‘/tmp/buildpacks/heroku-buildpack-ruby’…

—–> Compiling Ruby/Rails

—–> Using Ruby version: ruby-1.9.3

—–> Installing dependencies using 1.6.3




0 of 1 instances running, 1 starting

0 of 1 instances running, 1 starting

0 of 1 instances running, 1 starting

1 of 1 instances running

App started

Showing health and status for app mydemoapp in org user_example_com / space playground as…


requested state: started

instances: 1/1

usage: 512M x 1 instances


state     since                    cpu    memory           disk

#0   running   2014-09-30 12:10:52 PM   0.0%   128.2M of 512M   92.3M of 1G


The push command will show the output of the buildpack bundling process and create a summary at the end.

Log access

We are able to access our application’s log output by using the cf logs command like this:

[bash light=”true”]$> cf logs mydemoapp[/bash]

This will tail the application logs to your developer machine’s console.

You can test it by opening up your browser and accessing the application’s route. This will produce the following output:

[bash light=”false”] Connected, tailing logs for app mydemoapp in org user_example_com / space playground as…

2014-09-30T12:16:10.02+0200 [App/0]   OUT Started GET "/" for at 2014-09-30 10:16:10 +0000

2014-09-30T12:16:10.06+0200 [App/0]   OUT Processing by PostsController#index as */*

2014-09-30T12:16:10.15+0200 [App/0]   OUT   Rendered posts/index.html.erb within layouts/application (4.2ms)

2014-09-30T12:16:10.15+0200 [App/0]   OUT Completed 200 OK in 90.5ms (Views: 39.4ms | ActiveRecord: 7.3ms)


If you need to access older logs you can use the –recent parameter to display a dump of recent commands.

[bash light=”true”]$> cf logs mydemoapp –recent[/bash]

Additional help

The cf command line tool provides a help function to access the documentation.

[bash light=”true”]$> cf help[/bash]

This will display all available commands

Or in case you need help with a specific sub-command just use the –help paramenter like this:

[bash light=”true”]$> cf push –help[/bash]

This will display all available options for the cf push command.


As there are a lot of new commands to learn we created a cheatsheet with the most important commands for you. You can download it here.

One thought on “Introduction to the cf command line

  1. Pingback: Spring Cloud Netflix and CloudFoundry – Microservice / 12 Factor Application Resources | Cloudfoundry Rocks

Leave a Reply

Your email address will not be published.