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:

$> git clone

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:

$> 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:

$> 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:

$> cf target -o user_example_com -s playground

Service Creation

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

$> 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:

$> 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:

 $> 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:

$> cf push --help 

Let’s push our application to the servers:

$> 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:

$> 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:

$> 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:

$> cf logs mydemoapp

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:

 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.

$> cf logs mydemoapp --recent

Additional help

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

$> cf help

This will display all available commands

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

$> cf push --help

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.