diff --git a/Things-to-know-Kim.txt b/Things-to-know-Kim.txt
new file mode 100644
index 000000000..14ab3236b
--- /dev/null
+++ b/Things-to-know-Kim.txt
@@ -0,0 +1,61 @@
+Password for my computer: 123/*.
+There are 2 bootable partitions: kubuntu and Nixos
+The Nixos Setup files are on the usb stick on my desk if needed.
+Exoscale-Compute instances are our servers for production/stage/a runner for the automatic deployment and our gitea instance.
+All of them should be running! - There is no harm in restarting them if you need the password but you should leave your ssh key in there!
+
+
+I'll reroute my emails to one of you for software updates.
+
+
+MARIOS: Please make sure to patch out the vulnerable npm packages in the frontend.
+        And in my opinion, get started on React or Testcafe Integration tests ;)
+        You can add them into the Gitea Actions Pipeline, read the documentation on Github-actions and integration tests.
+
+Runner:
+    The runner runs our automatic deployment, every push on main for stage and every push including a v1.* version tag for production!
+    If the runner is not running, ssh into it and use the command sudo ./act_runner daemon in the ubuntu home directory.
+    If you need to see it in gitea it's under Actions->Runners
+    It follows the instructions in stage-deploy.yaml and prod-deploy.yaml in the /.gitea folder.
+  
+Gitea:
+    It's our github, you are all admins, don't stop/delete this service we don't have a backup as of now. (Maybe make one)
+    
+Webserver-Front-Back:
+    This is our production webserver it's setup is identical to the staging one.
+    Nginx/conf.d configuration file. Certbot is used for the ssh certificate and should automatically renew it.
+    in ~/backend there are the files from any backend compile/release and a service file. DON'T DELETE THE SERVICE FILE.
+    in ~/frontend the npm build release files are stored, the static main page needs to be copied to /var/www...etc the deploy does this.
+    
+Stage:
+    See above for Production.
+    
+Notes on the Backend:
+    Our Backend-Salt is not sufficient, use a random 10 letter string appended instead and remove it for checks...I might do this before I go.
+    Check the program.cs and the Controller.cs for everything, everything is in there.
+    We load our database in memory and save a copy after every change - This allows us for fast querying but if the db or the number of changes get big you might need to patch this out
+    We revoke the S3-Bucket read-keys once a day, these are per-installation not per user and for each installation we have 2 IAM-Roles one for generating read-keys and one for generating write keys. 
+    Write Keys are not to be changed! They would have to be set on each installation manually again. -> We need to automate this in the future.
+
+Vrm-Grabber:
+    The Vrm-Grabber is hosted on vrm.innov.energy.
+    It's code is fairly simple so go ahead and read it. It's basically a small backend that serves a dynamically generated table.
+    It grabs all the installation from Victrons vrm and displays a couple of basic things about them.
+    It changes the device-names to match the installation names!
+    It allows for updating all the batteries, just rename the FirmwareVersion and give it the new file.
+    Make sure to change the Victron-Alarms, they are automatically set on the update so just change them in the program!
+    It's useful for ssh-ing into them or checking for problems.
+    Updating it's db takes forever as Victron has a call-limit, it normally goes through the list once every ~8 hours so the online status is slow to catch up.
+    On startup it randomises the list of installations, if the program crashes frequently and gets restarted by the watchdog we will still update all the installations.
+    
+
+S3Explorer:
+    This is a simple CLI-tool you can use to grab data from our Salimax-Installation buckets. Try it it's simple. Find its -secret.
+    
+Python:
+    I'd recommend all of you to take a look at lsdbus dbus-spy and dbus-log they are invaluable for debugging installations and Ivo and I put a lot of effort into them.
+    upload-bms-firmware could use a rewrite but it works as of now...
+   
+make_deploy
+    My first work here don't judge it to harshly. It is used to prepare a tar file, which on a usb-stick plugged into any Victron installation on startup will update it to include our software and scripts. 
+    It's useful if you have physical access to an installation.
\ No newline at end of file