大多數python框架都會有一個某種開發webserver，它會有一個警告，說它不能用作生產服務器。他們傾向於從他們的生產等同物中得到多少不同？發展網絡服務器與生產網絡服務器有多接近？
我還沒有完全決定去哪個框架用，更談不上用什麼生產服務器，因此它還挺我很難腳，這歸因於「比較開發服務器x到生產服務器年。」所以說，讓我把這個問題更精確一些：根據你過去使用python框架的經驗，一旦你的應用程序在開發過程中被開發出來，你需要花費多少時間才能使你的應用程序運行起來並運行在生產系統上服務器？或者你是否跳過了開發服務器，並在更像你在生產中使用的服務器上開發你的應用程序？
較低的環境應儘量與生產環境儘可能地給出可用的資源相匹配。這適用於所有開發工作，無論它們是基於python還是基於web。實際上，大多數組織不願意花這種錢。在這種情況下，儘量讓生產環境直接低於生產環境。
一些變量要記住的是：
多次有在生產多臺機器（應用服務器，數據庫服務器，Web服務器，負載均衡器，防火牆等）。記住這一切。
操作系統
CPU的數量。從一個CPU較低的環境轉移到多核心生產環境可能會暴露未經過測試的多線程問題。
負載均衡。很多時候，較低的環境不會負載平衡。如果要複製到多個生產應用服務器會話（例如），你應該嘗試做同樣的在一個較低的環境
軟件/庫版本
一般來說，它們在其中需要運行，其中包括環境設置的應用程序的設置條件相同。
然而，客戶基本上具有開發系統，其在處理能力和其他硬件資源方面不那麼強大。我已經看到在開發環境中使用它們的虛擬服務器，因爲它們通常有多個並行的項目，這有助於他們降低成本。
理想的是，開發，測試和生產服務器的邏輯配置應該是相同的。他們應該具有相同版本的操作系統，Web服務器以及用於運行應用程序的所有其他軟件資產。然而，取決於你的環境的強大程度會產生什麼樣的影響 - 在開發機器上手動複製圖像/腳本等，而不是通過測試和/或生產。
減少這種你可能需要某種形式的推腳本，可以從一個階段打動你到下一個，即PushVersionDev，PushVesionTest，PushVersionProd。理想情況下，這應該是與目標服務器的參數相同的腳本，它們代表您需要通過各個階段移動應用程序所需的全部參數。
我會建議西奧Schlossnagle的書Scalable Internet Architectures的讀對此事更多的想法。
要直接回答你的問題....一旦你的應用程序測試和實施，到productoin的時間不是很大 - 部署操作系統，Web服務器，支持框架，如果他們需要安裝，應用程序，你很好去。從裸機上我看到linux服務器在1小時內上線，窗口大約90分鐘。如果你的操作系統和網絡服務器的運行時間更少......分鐘。
我和Django開發。我們擁有的生產服務器是遠程的，因此使用它進行開發是一件痛苦的事情。因此，起初，我創建了一個虛擬機，並嘗試儘可能匹配產品服務器的環境。在某種程度上vm得到了解決（由於一個不相關的事件）。當時我考慮了這種情況，並意識到使用定製虛擬機進行開發確實沒有什麼好的理由。由於應用程序可用的資源與prod服務器不同，因此無論如何（絕對意義上）對時序查詢都沒有好處。
這就是說，我現在使用django內置的開發sqlite開發服務器，以及用於生產的apache/wsgi和postgresql。只要雙方都滿足python依賴關係，它就是100％兼容的。唯一的潛在問題是編寫原始的sql而不是使用orm。
您的臨時環境應該模仿您的生產環境。發展更像是一個遊樂場，對發展環境的控制應該不那麼嚴格。但是，應定期從生產環境中刷新開發環境（例如，將prod數據複製到dev db，關閉dev上關閉prod的端口等）。
理想情況下，dev，stage和prod都在單獨的機器上。根據預算/需求，單獨的機器可以是單獨的物理機箱，也可以是同一物理機箱上的虛擬機。