如果你的做法是在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之間同步
: : 你遇到的不是平台的問題 而是它的設計就是如此