في التثبيت القياسي، يعمل Discourse (وبالتالي المكونات الإضافية) داخل حاوية Docker. لا تمتلك هذه الحاوية وصولاً كاملاً إلى نظام ملفات المضيف، لذا لا يمكنها الوصول إلى الدليل /var/discourse الخاص بالمضيف لتعديل app.yml أو تشغيل launcher.
وحتى لو كان بإمكانها… هناك تبعية دائرية بعض الشيء هنا. سيؤدي تشغيل ./launcher rebuild إلى إنهاء حاوية Docker… مما سيؤدي إلى إنهاء launcher rebuild الذي بدأته من المكون الإضافي 
هناك حلول محتملة هنا. على سبيل المثال، إضافة وحدات تخزين إضافية لـ Docker، بحيث يمكن الوصول إلى التكوين/المشغل من داخل الحاوية. لكن الأمر ليس سهلاً.
على حد علمي، قام شخص ما ذات مرة بإنشاء مكون إضافي “لمدير المكونات الإضافية”… والذي تطلب بعض التعديلات على app.yml لإضافة أشياء مثل وحدة التخزين. لكنني لا أستطيع العثور على أي مواضيع حوله الآن، لذا أفترض أنه لم يعد مدعومًا. ربما يمكن لشخص آخر مشاركة رابط إذا تمكن من العثور عليه؟ (أو ربما كان كل ذلك مجرد حلم 
)
من جانب CDCK، نميل بالتأكيد نحو استخدام السمات عندما نريد أن يتمكن العملاء من التثبيت/التحديث/إلغاء التثبيت حسب الرغبة. السماح للأشخاص بتثبيت المكونات الإضافية بشكل عشوائي ليس خيارًا، لأن ذلك سيؤثر على العملاء الآخرين الذين يعملون على نفس الخادم.