diff --git a/content/u/blog/2022-06-03-django-hosting-in-kubernetes/contents.lr b/content/u/blog/2022-06-03-django-hosting-in-kubernetes/contents.lr
index 8731782..eb1e40d 100644
--- a/content/u/blog/2022-06-03-django-hosting-in-kubernetes/contents.lr
+++ b/content/u/blog/2022-06-03-django-hosting-in-kubernetes/contents.lr
@@ -46,27 +46,41 @@ might potentially even come from a private registry.
 
 All of our Django applications are using Postgresql for storing
 data. Postgresql is used by quite some other applications that we
-deployed in k8s, so this is a no-brainer - Django hosting at ungleich
-even in k8s will be based on Postgresql.
+deployed in k8s, so this is a no-brainer. Django hosting at ungleich,
+even in k8s, will be based on Postgresql.
 
 Static data of Django applications can easily be stored on a PVC. This
 has the drawback that filesystem PVCs based on ceph block devices are
-RWO and thus in case of restart, there will be a short downtime.
+usually RWO and thus in case of restart, there will be a short downtime.
 
 This is, generally speaking probably accepted, like a deploy would
 have caused a short downtime on a VM as well.
 
 However alternatives would be a shared filesystem (such as
 NFS/CephFS), but they are usually slower than dedicated block
-devices.
+devices - so reliability can be traded against speed. Maybe we offer
+both options or add an NFS server as an option to our Django Hosting.
 
 
-## Django startup
+## Django startup / processes
 
 On startup, Django will need to ensure the database schema
 has been upgraded to the latest version. so something like `python
 manage.py migrate` should probably be called in an InitContainer for
-most apps.
+most apps. We could specify that the customer provided container
+supports multiple commands:
+
+- /init - anything that needs to be done *once* on startup
+- /run  - something that runs the actual site
+
+Some django apps however utilise Celery
+or [Django Q](https://django-q.readthedocs.io/en/latest/)
+for async tasks. We don't know which system is used, but it would be easy to
+add a flag to the hosting whether or not a third container
+should be utilised. Thus we could define:
+
+- If async container is defined, enable it and run /async (or similar)
+
 
 ## Secrets
 
@@ -88,8 +102,8 @@ write for each client/customer.
 
 This probably includes:
 
-- Possible encrypted secrets
-- Image definition
+- (Possible encrypted) Secrets
+- Image definitions
 - Maybe even (part of) a pod definition?
 
 Some parameters are likely to be stored in a different, ungleich only
@@ -98,3 +112,8 @@ writable repository, such as:
 - Size of RAM
 - Number of CPUs
 - Storage size (Postgresql, Static files, ...)
+
+## Status
+
+This document is still WIP and will be used as a basis for
+deploying our own Django apps first.
\ No newline at end of file