如果你的做法是在CMS运行在dyno上才进行安装plugin
那当然会消失
实际的细节是
source code->slug->dyno
https://devcenter.heroku.com/articles/slug-compiler
slug包含你的应用程式档案，和执行你的应用程式所需的环境
像是php, apache等
当heroku要启动一个dyno时，就会用这个slug来安装在某个server上(dyno)
所以你必须要在local把你所需要的plugin和template装好才push上去
这样这些档案才会被包装在slug里面
下次重新启动dyno, 也才会有这些档案
如果你是在运行的时候才装，你的确可以装在上面
但是这些档案并没有被打包压缩在slug里
所以才会造成说sleep后重新启动档案不见的状况
至于所谓sleep的状态，实际上是你的dyno整个被关掉了
下次新的request进来，heroku会用打包好的slug去产生出一个全新的dyno
这边有我之前的分享，请参考第5页
http://www.slideshare.net/YuChengWang/heroku-git-push-run
※ 引述《jimmytzeng (jimmytseng)》之铭言：
: 感谢您的回答
: 我后来看了一下heroku dev center的说明
: DYNO确实是当我的code push上去后就会产生DYNO, 而不是我说的当有request进来才会产生
: 而平常DYNO只是处于sleep的状态
: 感谢指正
: 另外我后来详细的去了解的问题
: 发现不仅仅是config无法做储存,甚至连某些CMS在运作时所安装的plugins以及templates
: 都是会随着DYNO处于sleep状态后而消失
: 后来自己想到解决的方法
: 只能先在local端先架设一个简易的sever, 进行CMS的configuration以及plugins,templates的安装
: 当一切设定完毕,在push至heroku完成初始化设定
: ※ 引述《blue3 (啦啦啦)》之铭言：
: : 你要先了解heroku平台的设计原则
: : 才有办法设计出符合这个平台的应用程式
: : http://12factor.net/
: : 这是heroku创办人提出的12factor
: : 如果一个应用程式依照这12个原则去设计
: : 那么将可以更容易地被scale或是部署在不同的环境
: : 你的问题解决方式很简单，也是heroku建议的方式
: : 就是所有应用程式相关的设定，都应该透过环境变量的方式去设定
: : https://devcenter.heroku.com/articles/config-vars
: : 像是数据库，或是add-on的设定
: : 而dyno本身的设计必须是stateless的
: : 也就是不应该有任何的状态资料(session, file等)被储存
: : file应该透过第三方平台去存取
: : session则应写入数据库或是透过像memcached来做分布式快取
: : 这是因为dyno的设计，是建构在硬件可能随时坏掉的前提之上
: : 因此stateless的特性，让dyno不储存任何状态
: : 可以在dyno crash的时候，重新启动一个dyno来服务
: : 另外，修正一下你的说法，
: : 并不是一个request进来才会产生一个dyno,
: : dyno在你push code到heroku时就会产生了
: : 如果你只有一个dyno, 才会有sleep的效应
: : 也就是你说的，太久没用被卸载来减轻平台本身的负担
: : 当"第一个"request进来，才会再产生一个dyno
: : 如果你有两个dyno, 就不会sleep
: : 但是两个dyno的状况下，就要让session可以在不同dyno之间同步
: : 你遇到的不是平台的问题 而是它的设计就是如此