# Windows installation

This topic is quite new to us, although a lot of ideas have been brought to the table.

## Chocolatey

A new idea came up with the package manager Chocolatey, which can install multiple dependencies on a system: NodeJS, MongoDB and OctoFarm. This has been shown to work, but there are challenges: privileges, migration of existing setups, git CLI vs choco update.

**Privileges**
When installing using any Windows installer, it is often assumed that admin privilege (Run As Admin) is required. However, running or adjusting files installed using this privilege then can throw errors.
We notice that `pm2` throws the EPERM error when we try to manage the OctoFarm service without Run As Admin.

Possible undetermined causes:
- `pm2` is installed in NPM user folder, which is not equal to `AppData\Roaming\npm\node_modules`
- pm2 is installed Admin only
- pm2 creates service which is somehow Admin only
- OctoFarm files are copied and flagged as Admin only

_Question 1 - can we tolerate that commands now need to be run as Admin?_
My answer would be: no, we didnt need to before so it would be highly confusing. Also, I am not used to running tools or CLI's as Admin, so to me it sounds like a big no. Example: `docker` also does not require admin rights.

**New systems**
Lets assume we have avoided the privilege situation, chocolatey works a charm for both manual install and upgrading.
There's one problem though, although we can script anything in the installer or updater powershell script, we are restricted in what we are allowed to do:
- We can only install or modify our own package (being OctoFarm or pm2)
- In other words, we can not mess around with checking or modifying mongo or nodejs. These are listed as dependencies, installed and constrained before our installer context.

_Question 2 - Should we create an setup installer which encapsulates chocolatey commands so we gain back control without breaking the choco installation requirements?_

**Migration**
Existing systems will have MongoDB and NodeJS already installed.

_Question 3 - Can this lead to confusion? Some dependencies could be installed twice now. Depends on Question 2. Shouldnt we avoid this?_

## Installation
We want to install OctoFarm as a service. We dont assume the choice for pm2, nssm, node-windows, direct service or a daemon is made just yet. (Do note we must have a service registration or a daemon service in the end).

Our code currently is highly coupled to: pm2, npm and git. This is a problem.

_Question 4 - Should OctoFarm be coupled to the installation or updating actions at all? Shouldnt we avoid assuming anything about how it is installed or updated and let other things manage that?_

**Updating**
This topic covers our work on how we update OctoFarm as we should most likely move away from `git pull`, because it is dependent on the state of the folder (modified files) and current branch. Users dont care about modified files, or branch and its bad to give them limited control of something they do not understand.

- Remove .git folder (already done in release ZIP)
- Replace git-dependent updater code with 'insert package manager here'
- Extract OctoFarm in a new folder for each update: same as OF-installer or chocolatey.

_Question 5 - Is off-loading and isolating the update completely a solution here?_

**Air gapped**
We dont have a portable version of OctoFarm yet we support air-gapped farms.

_Question 6 - is downloading NPM modules CPU heavy or network speed dependent?_

**Dependencies**
We want to get rid of OctoFarm `node_modules` or bring them along to users.

_Question 7 - Is npm or yarn not a developer tool? Shouldnt users get the 'same result' at all times?_

1) We definitely saw potential in PKG, but problems arise with the internal and external folders. This problem is 100% avoidable in our code, but it is super bug prone (especially if external npm modules do not work anymore).
2) We also see that PKG's size is quite big and there seems to be no tree-shaking or optimization of packages. No control or parameters on how it works.

_Question 8 - What is the risk of using PKG as it is right now? Can we find alternatives?_

## Service

We know about a lot of ways to run OctoFarm in such a way that it can reload on failures, updates or restarts.

- docker
- pm2
- nssm
- node-windows
- windows service (directly)
- daemonized (managed by another daemon of our own)

_Question 9 - How much is making our own daemon reinventing the wheel?_

I do think it gives us back control so much:
- We can create the same daemon for Windows, Linux and others.
- We can monitor our server's resources, down and up-time.
- We can call the daemon to restart our service from the browser
- We can manage our OctoFarm process from our code
- We can add extra tools: telemetry like anonymous statistics, diagnostics reports, etc.