常规的应用，大多数可以不经过任何修改即可部署于CloudFoundry云平台之上，但是在一些特殊情况下，总是不可避免地会出现一些细小的问题，如果在应用设计之初，就考虑到针对云平台的一些特殊情况，遵守云平台的规范，就会使应用更适应云平台环境，不止是CF平台，也包括其他的云平台，下边列举几条在应用设计之初应该考虑的情况：
1、避免使用本地文件系统
部署于CloudFoundry云平台的应用，在设计之时，应该避免对本地（服务器端）文件进行读写，原因如下：
1.1 应用实例的本地文件系统是短暂存在的
应用实例的本地文件系统依赖于当前应用实例的生命周期，这就意味着，当应用实例停止、重启或者崩溃的时候，原本分配与本实例的存储空间会被平台回收刷新病重新用于分配给新的应用实例，其中的所有数据即使是应用本身对这部分做出的修改也会被清除。
1.2 应用的不同实例的文件系统是各自独立的
在CloudFoundry环境中，所有的实例都是运行在一个“信息孤岛”之中，warden组件为每个实例构造了一个完全独立的运行环境，包括本地文件系统、内存等，即使是同一应用的不同实例，也是如此；而对于客户端来说，不同的客户端可能连到了不同的实例上，这就会出现什么现象，当一个客户端在应用的本地文件系统中写入了数据，另一个客户端同步读取，也会有可能读取不到任何数据，当然，如果刚好这两个客户端是连到了同一个实例上，而且实例在写入数据后没有发生类似重启、停止、崩溃的事件，那数据的读取还是正常的。
若有需求需要存储的数据需要贯穿应用实例的不同的生命周期，或者需要在不同的应用实例之间共享，最好的选择就是使用数据库或者Blob等存储服务，例如，可以使用部署于CloudFoundry环境上的MongoDB服务来存储非结构化的数据，使用其他关系型数据库如Mysql来存储结构化数据，另外，也可以使用如 Amazon S3, Google Cloud Storage, Dropbox，Box等公共服务，如果单是需要不同实例之间进行通讯或者数据共享，可以考虑使用Redis或者RabbitMQ等。
2、HTTP Session的非持久化与不可复制性
在客户端Cookie开启的情况下，CloudFoundry完全能够通过HTTP请求支持Session的关联和绑定，如果一个应用有多个实例，那么针对于某一客户端来说，它的所有请求，都会被路由到同一个应用实例，这就不会出现Session丢失的情况，这就允许服务器端可以对每个客户端进行一些Session临时数据的存储并在有效期内共享。
CloudFoundry平台本身不提供Session数据持久化和复制，如果一个应用实例出现崩溃或者停止、重启之类的事件，临时存储在HTTPsession中的数据将会丢失，这和上一条规范“避免本地文件系统读写”是密切相关的，当客户端与崩溃或者停止后重启的应用实例重新建立连接时，目标实例已经是一个全新的实例，而不是之前的实例，所以之前的session信息也已经不存在了。
对于那些在实例重启后仍然需要可用或者说可以在不同实例之间共享的Session数据，解决办法同上上一条规范：将数据保存在CloudFoundry的其他服务如redis、mysql或者其他开放的存储服务中。
3、HTTP和HTTPS端口的局限性
运行在CloudFoundry上的应用只能通过配置的URL接收数据，端口使用标准的HTTP端口-80和HTTPS端口-443。
CloudFoundry V2版本中的Mysql、redis、mongodb等服务可以通过CloudFoundry合作伙伴提供的客户端工具直接连接，而配置连接参数和认证参数可以通过查看绑定了该服务的应用的env.log文件或者CloudFoundry API接口获得。