VI. Processes
รันแอพพลิเคชันเป็นหนึ่งหรือมากกว่าให้เป็น stateless processes
App ทํางานในสภาพแวดล้อมการดําเนินงานด้วยหนึ่งหรือมากกว่า processes
ในกรณีที่ง่ายที่สุดคือ code คือ stand-alone script, สภาพแวดล้อมการดําเนินงานคือเครื่องคอมพิวเตอร์อง developer ที่ติดตั้ง language runtime และวิธีการคือเปิด app ด้วยคําสั่ง (ตัวอย่างเช่น python my_script.py) ในอีกด้านหนึ่ง app ที่ซับซ้อนที่ deploy บน production ใช้หลาย process types, instantiated into zero or more running processes
Twelve-factor processes เป็น stateless และ share-nothing. ข้อมูลใดๆที่จําเป็นต้องเก็บแบบถาวรจําเป็นต้องเก็บไว้ใน stateful backing service โดยปรกติจะเป็นฐานข้อมูล
พื้นที่หน่วยความจําหรือระบบไฟล์ของ process สามารถใช้เป็นช่วงสั้นๆ ได้, single-transaction cache. ตัวอย่างเช่น, การดาวน์โหลดไฟล์ขนาดใหญ่, ดําเนินงานกับไฟล์นั้น และเก็บผลลัพธ์ของการดําเนินงานไว้ในฐานข้อมูล twelve-factor app ไม่เคยสมมติว่ามีอะไรแคชในหน่วยความจําหรือบน disk จะพร้อมใช้งานใน request หรือ job ในอนาคต – มีหลาย process ทํางานมีโอกาสสูงมากที่ในอนาคต request จะทํางานบน process ที่แตกต่างกัน แม้ว่าทํางาน process เดียว เมื่อมีการ restart (trigger โดย code deploy, config change หรือเปลี่ยนสภาพแวดล้อมการทํางาน) จะลบสภานะของ app ทั้งหมดอย่างสมบูรณ์ (เช่น หน่วยความจํา และระบบไฟล์)
Asset packagers อย่างเช่น django-assetpackager ใช้ระบบไฟล์เป็นแคชของการ compiled asset. Twelve-factor app ชอบที่จะทํา compiling เช่นนี้ในระหว่าง ขั้นตอนการ build Asset packagers อย่างเช่น Jammit และ Rails asset pipeline สามารถตั้งค่าให้ pacakge asset ระหว่างขั้นตอนการ build ได้
บางระบบเว็บขึ้นอยู่กับ "sticky sessions" – นั้นคือ, ทําการแคชขอมูล user session ในหน่วยความจําของ app สําหรับดําเนินการในอนาคตจากผู้เยี่ยมชมเดียวกันที่เชื่อมโยงกับ process เดียวกัน, Sticky session เป็นการละเมิด twelve-factor และไม่ควรใช้หรือพึ่งพา, ข้อมูลสถานะ Session เป็นสิ่งที่เหมาะสมอย่างมากสําหรับที่เก็บข้อมูลที่มีการหมดเวลา (time-expireation) อย่างเช่น Memcached หรือ Redis