Deploying a Cloud Foundry v2 Application to New Pivotal Cloud Environment

Cloud Foundry v2 has been talked about for a while – and being an open-source project, it’s easy to follow along with the roadmaps, docs, and source code – and now it’s being released into the wild. Cloud Foundry is shepherded by Pivotal (spun off from VMware earlier this year) and they have launched a hosted version of Cloud Foundry v2. It has a free trial and a series of paid tiers (coming soon). Unlike most public PaaS platforms, Cloud Foundry can also be run privately and that’s where Pivotal is expected to focus.

I’ve deployed a fair number of apps to Cloud Foundry environments over the past two years (including Tier 3’s Web Fabric that introduces .NET support) and wanted to take this new stuff for a spin. I built a Node.js v0.10.11 application (source code here) to check out the new deployment and management experience offered by Pivotal.

This basic application uses the secret Google API to do currency conversion. The app ran fine on my local machine and was almost ready for the Pivotal cloud.


Deploying an application

Instead of using the old vmc command for interacting with Cloud Foundry environments, we now have the cf command tool for targeting Cloud Foundry v2 environments. The first step was to install cf. Then I prepared my application for running in Cloud Foundry v2. Note that I had to make two changes that I never had to make when deploying to Cloud Foundry v1 environments. First, I had to explicitly set my Node version in the package.json file. The docs imply that this is optional, but my deployment failed when I didn’t have it there. Nonetheless, it doesn’t hurt anything. So, my package.json file looked like this:

  "name": "serotercurrencyconverter",
  "version": "0.0.1",
  "private": true,
  "scripts": {
    "start": "node app.js"
  "dependencies": {
    "express": "3.2.6",
    "jade": "*"
   "engines": {
   "node": ">= 0.10.0"

The second change I made involved setting the start command for my Node.js application. I can’t recall ever being forced to do that before, although once again, it’s not a bad thing. This YML file was generated for me during deployment, so we’ll get to that in a moment.

I started a command prompt and navigated to the directory that held my Node app. In then used the cf target command to point the cf tool at the Pivotal cloud. Then I used cf login to provide my credentials and chose a “space”; in this case, my “development” space. The cf push command started the ball rolling on my deployment. I was asked for an application name, instance count, memory limit, domain, and associated services (e.g. database, messaging). Finally, I was asked if I want to save my configuration, and I said yes.


After a few moments, I get an error saying that I failed to provide a start command and therefore my application didn’t stage. No problem. I opened up the manifest.yml file that was automatically added to the project, and added an entry indicating how to start the application.

- name: serotercurrency
  memory: 64M
  instances: 1
  path: .
  command: node app.js

I did another cf push with a —reset flag to make sure it accepted the updated yml file. A few seconds, later, my app shows as running.


Sure enough, visiting the application URL pulls up the (working) page.


Interacting with the app from the console

Congrats to me, I’ve got an app deployed! The new cf tool has a lot more functionality than the old vmc tool did. But you’ll still find all the important operations for managing and maintaining your applications. For instance, I can easily see all the applications that I’ve deployed using cf apps.


Scaling an application was simple. I simply ran cf scale and provided the application name, which dimension to scale (app instances, memory, storage) and the amount.


Interested in the utilization statistics of an application? Just run cf stats to see how much CPU, memory and disk is being consumed.


All very good stuff. Take a look at all the commands that cf has to offer. Next up, let’s see the fancy new portal for managing Pivotal-hosted Cloud Foundry v2 applications.

Interacting with the app from the Pivotal management portal

Up until now, most of my interactions with Cloud Foundry environments were through vmc. Many hosting vendors created GUI layers on top, but I honestly didn’t spend too much time with them. The new Cloud Foundry management experience that Pivotal offers is pretty slick. While not nearly as mature yet as other leading PaaS portals, it shows the start of a powerful interface. Note that this web-based interface will likely be Pivotal-specific and not checked in to the public source code repository. It represents a value-added feature for those who come to Pivotal for their commercial Cloud Foundry offering.


Cloud Foundry v2 has the concepts of organizations, spaces, and applications. I have an organization called “Seroter”, and default “spaces” for development, staging, and production. I can add and delete spaces as I see fit. This structure provides a way to segment access to applications so that companies can effectively control who has what type of access to various application containers. In my development space, you can see that I have a single application, and a single user.


I can invite more users to my space, and assign them one of a handful of pre-defined (and fixed) roles. There are broad organization-based roles (organization manager, billing manager, auditing manager), and three space-based roles (space manager, space developer, space auditor).


Drilling into an individual application shows me the health of the application, instance count, bound services, utilization statistics, uptime, and more.


It doesn’t appear that Pivotal is offering their own hosted services as before (databases like PostgreSQL and MongoDB; messaging services like RabbitMQ) and is leveraging a marketplace of cloud providers. If you choose to add a new service – or click the “marketplace” link on the top navigation – you’re taken to a view where a handful of providers offer a variety of application services.



There’s lots to like about Cloud Foundry v2. It’s undergone some significant plumbing changes while retaining a familiar developer experience. The cf tool is a big upgrade from the previous tool, and the Pivotal management portal provides a very nice interface that flexes some of the structural changes (e.g. spaces) introduced in Cloud Foundry v2. For companies looking for a public or private PaaS that works well with multiple languages/frameworks, Cloud Foundry should absolutely be on your list.

Author: Richard Seroter

Richard Seroter is Director of Developer Relations and Outbound Product Management at Google Cloud. He’s also an instructor at Pluralsight, a frequent public speaker, the author of multiple books on software design and development, and a former editor plus former 12-time Microsoft MVP for cloud. As Director of Developer Relations and Outbound Product Management, Richard leads an organization of Google Cloud developer advocates, engineers, platform builders, and outbound product managers that help customers find success in their cloud journey. Richard maintains a regularly updated blog on topics of architecture and solution design and can be found on Twitter as @rseroter.

2 thoughts

  1. Great post Richard, I’m a big fan of Cloud Foundry, the position in the market it holds and its target/future state, great to see V2.0 out in the wild and looking forward to a GA release for the enterprise.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.