diff --git a/content/u/blog/2024-10-13-staticcms-moved-to-kubernetes/contents.lr b/content/u/blog/2024-10-13-staticcms-moved-to-kubernetes/contents.lr
new file mode 100644
index 0000000..132ac07
--- /dev/null
+++ b/content/u/blog/2024-10-13-staticcms-moved-to-kubernetes/contents.lr
@@ -0,0 +1,109 @@
+title: Our staticcms has been moved to kubernetes!
+---
+pub_date: 2024-10-13
+---
+author: ungleich web team
+---
+twitter_handle: ungleich
+---
+_hidden: no
+---
+_discoverable: yes
+---
+abstract:
+One more service in k8s
+---
+body:
+
+## Moved to kubernetes
+
+This website and all static content has been moved to Kubernetes as of
+2024-10-13. The motivation and background is very similar to what
+[Nico wrote on his
+blog](https://www.nico.schottelius.org/blog/2024-10-11-moving-into-k8s/)
+already some days ago.
+
+## Build system for teams
+
+Differently to what Nico is doing with his private homepage, this
+website will be moved into a "fancy build" system. The background is
+that while for a single person running `make` on the laptop which
+modifies argocd cluster configurations, for a team of people working
+on the website, things are a bit more difficult.
+
+For once, not every computer at ungleich is running Linux, we do have
+some non-Linux machines and also machines not run by our kubernetes
+team, so there is no direct argocd access. And neither is docker build
+available on some machines.
+
+How the build pipeline will look exactly is still to be defined, but
+once we have settled on one, you will link the details here - so stay
+tuned for updates.
+
+## Static websites pattern
+
+One thing we would like to share is already the structure of the helm
+chart we are using for deployment: We have one helm chart that uses a
+list of containers that should be deployed. Deployed by argocd
+it essentially looks like this:
+
+```
+apiVersion: argoproj.io/v1alpha1
+kind: Application
+metadata:
+  name: staticweb-nico
+  namespace: argocd
+  finalizers:
+  - resources-finalizer.argocd.argoproj.io
+spec:
+  destination:
+    namespace: nico
+    server: 'https://kubernetes.default.svc'
+  source:
+    path: apps/prod/staticweb
+    repoURL: '...'
+    helm:
+      valuesObject:
+        websites:
+          - name: www-nico
+            image:
+              harbor.k8s.ungleich.ch/nico/www.nico.schottelius.org:559c0c45
+            fqdn: www.nico.schottelius.org
+  project: default
+  syncPolicy:
+    automated:
+      prune: true
+      selfHeal: true
+    syncOptions:
+      - CreateNamespace=true
+```
+
+The name attribute is used for defining the k8s `Deployment`, the fqdn
+is passed to the nginx-ingress and the image should be pretty clear.
+
+You may notice that we use our own image registry based on
+harbor. Not only is this much faster for pulling images, but it also
+solves problems with other registries:
+
+* github (ghrc.io) is legacy IP only and cannot be used from the
+  Internet
+* docker hub has very strict pull limits, often not allowing us to
+  pull in images. While this can be worked around with using a login
+  token, it add a certain complexity to our infrastructure deploying
+  logins for various registries.
+
+This brings us to something some of you might have noticed already:
+
+## Our containers are publicly reachable
+
+Anyone can download any container hosted on our harbor instance
+without authentication. This is by design, as containers should only
+contain public data. All our containers contain public, open source
+applications only.
+
+Data is being injected either by an sqldump in the beginning (if it is
+an existing application) or generated at startup or passed in as a
+secret independently of the container.
+
+From our perspective this principle allows easy and strict separation
+of private vs. public data.