add docsite (docusaurus v3)

docsite/.gitignore

@@ -0,0 +1,20 @@
+# Dependencies
+/node_modules
+
+# Production
+/build
+
+# Generated files
+.docusaurus
+.cache-loader
+
+# Misc
+.DS_Store
+.env.local
+.env.development.local
+.env.test.local
+.env.production.local
+
+npm-debug.log*
+yarn-debug.log*
+yarn-error.log*

docsite/README.md

@@ -0,0 +1,41 @@
+# Website
+
+This website is built using [Docusaurus](https://docusaurus.io/), a modern static website generator.
+
+### Installation
+
+```
+$ yarn
+```
+
+### Local Development
+
+```
+$ yarn start
+```
+
+This command starts a local development server and opens up a browser window. Most changes are reflected live without having to restart the server.
+
+### Build
+
+```
+$ yarn build
+```
+
+This command generates static content into the `build` directory and can be served using any static contents hosting service.
+
+### Deployment
+
+Using SSH:
+
+```
+$ USE_SSH=true yarn deploy
+```
+
+Not using SSH:
+
+```
+$ GIT_USER=<Your GitHub username> yarn deploy
+```
+
+If you are using GitHub pages for hosting, this command is a convenient way to build the website and push to the `gh-pages` branch.

docsite/babel.config.js

@@ -0,0 +1,3 @@
+module.exports = {
+  presets: [require.resolve('@docusaurus/core/lib/babel/preset')],
+};

docsite/docs/build-images/choosing-builder.md

@@ -0,0 +1,9 @@
+# select a builder
+
+A builder is a machine running monitor periphery and docker. Any server connected to monitor can be chosen as the builder for a build.
+
+Building on a machine running production software is usually not a great idea, as this process can use a lot of system resources. It is better to start up a temporary cloud machine dedicated for the build, then shut it down when the build is finished. Right now monitor supports AWS ec2 for this task.
+
+### AWS builder
+
+You can choose to build on AWS on the "builder" tab on the build's page. From here you can select preconfigured AMIs to use as a base to build the image. These must be configured in the monitor core configuration along with other information like defaults to use, AWS credentials, etc. This is explained on the [core setup page](https://github.com/mbecker20/monitor/blob/main/docs/setup.md). 

docsite/docs/build-images/configuration.md

@@ -0,0 +1,29 @@
+# configuration
+
+monitor just needs a bit of information in order to build your image.
+
+### repo configuration
+To specify the github repo to build, just give it the name of the repo and the branch under *repo config*. The name is given like ```mbecker20/monitor```, it includes the username / organization that owns the repo.
+
+Many repos are private, in this case a Github access token is required in the periphery.config.toml of the building server. these are specified in the config like ```username = "access_token"```. An account which has access to the repo and is available on the periphery server can be selected to use via the *github account* dropdown menu.
+
+### docker build configuration
+
+In order to docker build, monitor just needs to know the build directory and the path of the Dockerfile relative to the repo, you can configure these in the *build config* section.
+
+If the build directory is the root of the repository, you pass the build path as ```.```. If the build directory is some folder of the repo, just pass the name of the the folder. Do not pass the preceding "/". for example ```build/directory```
+
+The dockerfile's path is given relative to the build directory. So if your build directory is ```build/directory``` and the dockerfile is in ```build/directory/Dockerfile.example```, you give the dockerfile path simply as ```Dockerfile.example```.
+
+Just as with private repos, you will need to select a docker account to use with ```docker push```. 
+
+### adding build args
+
+The Dockerfile may make use of [build args](https://docs.docker.com/engine/reference/builder/#arg). Build args can be passed using the gui by pressing the ```edit``` button. They are passed in the menu just like in the would in a .env file:
+
+```
+BUILD_ARG1=some_value
+BUILD_ARG2=some_other_value
+```
+
+Note that these values are visible in the final image using ```docker history```, so shouldn't be used to pass build time secrets. Use [secret mounts](https://docs.docker.com/engine/reference/builder/#run---mounttypesecret) for this instead.

docsite/docs/build-images/index.mdx

@@ -0,0 +1,15 @@
+---
+slug: /build-images
+---
+
+# building images
+
+Monitor builds docker images by cloning the source repository from Github, running ```docker build```, and pushing the resulting image to docker hub. Any repo containing a ```Dockerfile``` is buildable using this method.
+
+Build configuration involves passing file / directory paths, for more details about passing file paths, see the [file paths doc](/file-paths).
+
+```mdx-code-block
+import DocCardList from '@theme/DocCardList';
+
+<DocCardList />
+```

docsite/docs/build-images/pre-build.md

@@ -0,0 +1,7 @@
+# pre build command
+
+Sometimes a command needs to be run before running ```docker build```, you can configure this in the *pre build* section. 
+
+There are two fields to pass for *pre build*. the first is *path*, which changes the working directory. To run the command in the root of the repo, just pass ```.```. The second field is *command*, this is the shell command to be executed after the repo is cloned.
+
+For example, say your repo had a folder in it called ```scripts``` with a shell script ```on-clone.sh```. You would give *path* as ```scripts``` and command as ```sh on-clone.sh```. Or you could make *path* just ```.``` and then the command would be ```sh scripts/on-clone.sh```. Either way works fine.

docsite/docs/build-images/versioning.md

@@ -0,0 +1,3 @@
+# versioning
+
+Monitor uses a major.minor.patch versioning scheme. Every build will auto increment the patch number, and push the image to docker hub with the version tag as well as the ```latest``` tag. 

docsite/docs/connecting-servers/add-server.md

@@ -0,0 +1,7 @@
+# adding the server to monitor
+
+The easiest way to add the server is with the GUI. On the home page, click the ```+``` button to the right of the server search bar, configure the name and address of the server. The address is the full http/s url to the periphery server, eg ```http://12.34.56.78:8000```.
+
+Once it is added, you can use access the GUI to modify some config, like the alerting thresholds for cpu, memory and disk usage. A server can also be temporarily disabled, this will prevent alerting if it goes offline.
+
+Since no state is stored on the periphery servers, you can easily redirect all deployments to be hosted on a different server. Just update the address to point to the new server.

docsite/docs/connecting-servers/index.mdx

@@ -0,0 +1,16 @@
+---
+slug: /connecting-servers
+---
+
+# connecting servers
+
+Integrating a device into the monitor system has 2 steps:
+
+ 1. Setup and start the periphery agent on the server
+ 2. Adding the server to monitor via the core API
+
+```mdx-code-block
+import DocCardList from '@theme/DocCardList';
+
+<DocCardList />
+```

docsite/docs/connecting-servers/setup-periphery.md

@@ -0,0 +1,43 @@
+# setup monitor periphery
+
+The easiest way to do this is to follow the [monitor guide](https://github.com/mbecker20/monitor-guide). This is a repo containing directions and scripts enabling command line installation via ssh or remotely.
+
+### manual install steps
+
+ 1. Download the periphery binary from the latest [release](https://github.com/mbecker20/monitor/releases).
+
+ 2. Create and edit your config files, following the [config example](https://github.com/mbecker20/monitor/blob/main/config_example/periphery.config.example.toml). The monitor cli can be used to add the boilerplate: ```monitor periphery gen-config --path /path/to/config.toml```. The files can be anywhere, and can be passed to periphery via the ```--config-path``` argument.
+
+ 3. Ensure that inbound connectivity is allowed on the port specified in periphery.config.toml (default 8000).
+
+ 4. Install docker. Make sure whatever user periphery is run as has access to the docker group without sudo.
+
+ 5. Start the periphery binary with your preferred process manager, like systemd. The config read from the file is printed on startup, ensure that it is as expected.
+
+### example periphery start command
+
+```
+periphery \
+	--config-path /path/to/periphery.config.base.toml \
+	--config-path /other_path/to/overide-periphery-config-directory \
+	--config-keyword periphery \
+	--config-keyword config \
+	--merge-nested-config \
+	--home_dir /home/username
+```
+
+### passing config files
+
+Either file paths or directory paths can be passed to ```--config-path```.
+
+When using directories, the file entries can be filtered by name with the ```--config-keyword``` argument, which can be passed multiple times to add more keywords. If passed, then only config files with file names that contain all keywords will be merged.
+
+When passing multiple config files, later --config-path given in the command will always overide previous ones. Directory config files are merged in alphabetical order by name, so ```config_b.toml``` will overide ```config_a.toml```.
+
+There are two ways to merge config files. The default behavior is to completely replace any base fields with whatever fields are present in the overide config. So if you pass ```allowed_ips = []``` in your overide config, the final allowed_ips will be an empty list as well. 
+
+```--merge-nested-config``` will merge config fields recursively and extend config array fields. 
+
+For example, with ```--merge-nested-config``` you can specify an allowed ip in the base config, and another in the overide config, they will both be present in the final config.
+
+Similarly, you can specify a base docker / github account pair, and extend them with additional accounts in the overide config.

docsite/docs/core-setup.md

@@ -0,0 +1,40 @@
+# core setup
+
+setting up monitor core is fairly simple. there are some requirements to run monitor core:
+
+ - a valid configuration file
+ - an instance of MongoDB to which monitor core can connect
+ - docker must be installed on the host
+
+## 1. create the configuration file
+
+create a configuration file on the system, for example at `~/.monitor/core.config.toml`, and copy the [example config](https://github.com/mbecker20/monitor/blob/main/config_example/core.config.example.toml). fill in all the necessary information before continuing.
+
+:::note
+to enable OAuth2 login, you must create a client on the respective OAuth provider, 
+for example [google](https://developers.google.com/identity/protocols/oauth2) 
+or [github](https://docs.github.com/en/apps/oauth-apps/building-oauth-apps/authorizing-oauth-apps). 
+monitor uses the `web application` login flow.
+the redirect uri is `<base_url>/auth/google/callback` for google and `<base_url>/auth/github/callback` for github.
+:::
+
+## 2. start monitor core
+
+monitor core is distributed via dockerhub under the public repo [mbecker2020/monitor_core](https://hub.docker.com/r/mbecker2020/monitor_core).
+
+```sh
+docker run -d --name monitor-core \
+	-v $HOME/.monitor/core.config.toml:/config/config.toml \
+	-p 9000:9000 \
+	mbecker2020/monitor_core
+```
+
+## first login
+
+monitor core should now be accessible on the specified port, so navigating to `http://<address>:<port>` will display the login page. 
+
+the first user to log in will be auto enabled and made admin. any additional users to create accounts will be disabled by default.
+
+## https
+
+monitor core itself only supports http, so a reverse proxy like [caddy](https://caddyserver.com/) should be used for https

docsite/docs/deploy-containers/configuration.md

@@ -0,0 +1,83 @@
+# configuration
+
+## choose the docker image
+
+There are two options to configure the docker image to deploy. 
+
+### attaching a monitor build
+If the software you want to deploy is built by monitor, you can attach the build directly to the deployment.
+
+By default, monitor will deploy the latest available version of the build, or you can specify a specific version using the version dropdown.
+
+Also by default, monitor will use the same docker account that is attached to the build in order to pull the image on the periphery server. If that account is not available on the server, you can specify another available account to use instead, this account just needs to have read access to the docker repository.
+
+### using a custom image
+You can also manually specify an image name, like ```mongo``` or ```mbecker2020/random_image:0.1.1```.
+
+If the image repository is private, you can select an available docker account to use to pull the image.
+
+## configuring the network
+
+One feature of docker is that it allows for the creation of [virtual networks between containers](https://docs.docker.com/network/). Monitor allows you to specify a docker virtual network to connect the container to, or to use the host system networking to bypass the docker virtual network.
+
+The default selection is ```host```, which bypasses the docker virtual network layer.
+
+If you do select select a network other than host, you can specify port bindings with the GUI. For example, if you are running mongo (which defaults to port 27017), you could use the mapping:
+
+```
+27018 : 27017
+```
+
+In this case, you would access mongo from outside of the container on port ```27018```.
+
+Note that this is not the only affect of using a network other than ```host```. For example, containers running on different networks can not communicate, and ones on the same network can not reach other containers on ```localhost``` even when they are running on the same system. This behavior can be a bit confusing if you are not familiar with it, and it can be bypassed entirely by just using ```host``` network.
+
+## configuring restart behavior
+
+Docker, like systemd, has a couple options for handling when a container exits. See [docker restart policies](https://docs.docker.com/config/containers/start-containers-automatically/). Monitor allows you to select the appropriate restart behavior from these options.
+
+## configuring environment variables
+
+Monitor enables you to easily manage environment variables passed to the container. In the GUI, click the 'edit' button on the 'environment' card, this will bring up the environment menu.
+
+You pass environment variables just as you would with a ```.env``` file:
+
+```
+ENV_VAR_1=some_value
+ENV_VAR_2=some_other_value
+```
+
+## configuring volumes
+
+A docker container's filesystem is segregated from that of the host. However, it is still possible for a container to access system files and directories, this is accomplished by using [bind mounts](https://docs.docker.com/storage/bind-mounts/).
+
+Say your container needs to read a config file located on the system at ```/home/ubuntu/config.toml```. You can specify the bind mount to be:
+
+```
+/home/ubuntu/config.toml : /config/config.toml
+```
+
+The first path is the one on the system, the second is the path in the container. Your application would then read the file at ```/config/config.toml``` in order to load its contents.
+
+These can be configured easily with the GUI in the 'volumes' card. You can configure as many bind mounts as you need.
+
+## extra args
+
+Not all features of docker are mapped directly by monitor, only the most common. You can still specify any custom flags for monitor to include in the ```docker run``` command by utilizing 'extra args'. For example, you can enable log rotation using these two extra args:
+
+```
+--log-opt max-size=10M
+```
+```
+--log-opt max-file=3
+```
+
+## post image
+
+Sometimes you need to specify some flags to be passed directly to the application. What is put here is inserted into the docker run command after the image. For example, to pass the ```--quiet``` flag to MongoDB, the docker run command would be:
+
+```
+docker run -d --name mongo-db mongo:6.0.3 --quiet
+```
+
+In order to achieve this with monitor, just pass ```--quiet``` to 'post image'.

docsite/docs/deploy-containers/index.mdx

@@ -0,0 +1,11 @@
+# deploy containers
+
+Monitor can deploy any docker images that it can access with the configured docker accounts. It works by parsing the deployment configuration into a ```docker run``` command, which is then run on the target system. The configuration is stored on MongoDB, and records of all actions (update config, deploy, stop, etc.) are stored as well.
+
+Deployment configuration involves passing file / directory paths, for more details about passing file paths, see the [file paths doc](/file-paths).
+
+```mdx-code-block
+import DocCardList from '@theme/DocCardList';
+
+<DocCardList />
+```

docsite/docs/deploy-containers/lifetime-management.md

@@ -0,0 +1,15 @@
+# container management
+
+the lifetime of a docker container is more like a virtual machine. They can be created, started, stopped, and destroyed. monitor will display the state of the container and provides an API to manage all your container's lifetimes.
+
+this is achieved internally by running the appropriate docker command for the requested action (docker stop, docker start, etc).
+
+### stopping a container
+
+sometimes you want to stop a running application but preserve its logs and configuration, either to be restarted later or to view the logs at a later time. It is more like *pausing* the application with its current config, as no configuration (like environment variable, volume mounts, etc.) will be changed when the container is started again. 
+
+note that in order to restart an application with updated configuration, it must be *redeployed*. stopping and starting a container again will keep all configuration as it was when the container was initially created.
+
+### container redeploy
+
+redeploying is the action of destroying a container and recreating it. If you update deployment config, these changes will not take effect until the container is redeployed. Just note this will destroy the previous containers logs along with the container itself.

docsite/docs/file-paths.md

@@ -0,0 +1,31 @@
+# file paths
+
+when working with monitor, you might have to configure file or directory paths.
+
+## relative paths
+
+Where possible, it is better to use relative file paths. Using relative file paths removes the connection between the process being run and the particular server it runs on, making it easier to move things between servers.
+
+Where you see relative paths:
+
+ - setting the build directory and path of the Dockerfile
+ - setting a pre build command path
+ - configuring a frontend mount (used for web apps)
+
+For all of the above, the path can be given relative to the root of the configured repo
+
+The one exception is the Dockerfile path, which is given relative to the build directory (This is done by Docker itself, and this pattern matches usage of the Docker CLI).
+
+There are 3 kinds of paths to pass:
+
+ 1. to specify the root of the repo, use ```.``` as the path
+ 2. to specify a folder in the repo, pass it with **no** preceding ```/```. For example, ```example_folder``` or ```folder1/folder2```
+ 3. to specify an absolute path on the servers filesystem, use a preceding slash, eg. ```/home/ubuntu/example```. This way should only be used if absolutely necessary, like when passing host paths when configuring docker volumes.
+
+### implementation
+
+relative file paths are joined with the path of the repo on the system using a Rust [PathBuf](https://doc.rust-lang.org/std/path/struct.PathBuf.html#method.push).
+
+## Docker Volume Paths
+
+These are passed directly to the Docker CLI using ```--volume /path/on/system:/path/in/container```. So for these, the same rules apply as when using Docker on the command line. Paths here should be given as absolute, don't use ```~``` or even ```$HOME```.

docsite/docs/intro.md

@@ -0,0 +1,44 @@
+---
+slug: /intro
+---
+
+# what is monitor?
+
+If you have many servers running many applications, it can be a challenge to keep things organized and easily accessible. Without structure, things can become messy quickly, which means operational issues are more likely to arise and they can take longer to resolve. Ultimately these issues hinder productivity and waste valuable time. Monitor is a web app to provide this structure for how applications are built, deployed, and managed across many servers.
+
+## docker
+
+Monitor is opinionated by design, and [docker](https://docs.docker.com/) is the tool of choice. Docker provides the ability to package applications and their runtime dependencies into a standalone bundle, called an *image*. This makes them easy to "ship" to any server and run without the hassle of setting up the runtime environment. Docker uses the image as a sort of template to create *containers*. Containers are kind of like virtual machines but with different performance characteristics, namely that processes contained still run natively on the system kernel. The file system is seperate though, and like virtual machines, they can be created, started, stopped, and destroyed.
+
+## monitor
+
+Monitor is a solution for handling for the following:
+
+ 1. Build application source into auto-versioned images. 
+ 2. Create, start, stop, and restart Docker containers, and view their status and logs.
+ 3. Keep a record of all the actions that are performed and by whom.
+ 4. View realtime and historical system resource usage.
+ 5. Alerting for server health, like high cpu, memory, disk, etc.
+
+## architecture and components
+
+Monitor is composed of a single core and any amount of connected servers running the periphery application. 
+
+### monitor core
+The core is a web server that hosts the core API and serves the frontend to be accessed in a web browser. All user interaction with the connected servers flow through the core. It is the stateful part of the system, with the application state stored on an instance of MongoDB.
+
+### monitor periphery
+The periphery is a stateless web server that exposes API called by the core. The core calls this API to get system usage and container status / logs, clone git repos, and perform docker actions. It is only intended to be reached from the core, and has an address whitelist to limit the IPs allowed to call this API.
+
+### monitor cli
+This is a simple standalone cli that helps perform some actions required to setup monitor core and periphery, like generating config files. 
+
+## core API
+
+Monitor exposes powerful functionality over the core's REST API, enabling infrastructure engineers to manage deployments programmatically in addition to with the GUI. There is a [rust crate](https://crates.io/crates/monitor_client) to simplify programmatic interaction with the API, but in general this can be accomplished using any programming language that can make REST requests. 
+
+## permissioning
+
+Monitor is a system designed to be used by many users, whether they are developers, operations personnel, or administrators. The ability to affect an applications state is very powerful, so monitor has a granular permissioning system to only provide this functionality to the intended users. The permissioning system is explained in detail in the [permissioning](https://github.com/mbecker20/monitor/blob/main/docs/permissions.md) section. 
+
+User sign-on is possible using username / password, or with Oauth (Github and Google). Allowed login methods can be configured from the [core config](https://github.com/mbecker20/monitor/blob/main/config_example/core.config.example.toml).

docsite/docs/permissioning.md

@@ -0,0 +1,28 @@
+# permissioning resources
+
+All monitor resources (servers, builds, deployment) have independant permission tables to allow for users to have granular access to these resources. By default, users do not see any resources until they are given at least read permissions.
+
+## permission levels
+
+There are 4 levels of permissions a user can have on a resource:
+
+ 1. **None**. This is the lowest permission level, and means the user will not have any access to this resource. They will not see it in the GUI, and it will not show up if the user queries the core API directly. All attempts to view or update the resource will be blocked.
+
+ 2. **Read**. This is the first permission level that grants any access. It will enable the user to see the resource in the GUI, read the configuration, and see any logs. Any attempts to update configuration or trigger any action will be blocked.
+
+ 3. **Execute**. This level will allow the user to execute actions on the resource, like send a build command or trigger a redeploy. The user will still be blocked from updating configuration on the resource.
+
+ 4. **Update**. The user has full access to the resource, they can execute any actions, update the configuration, and delete the resource.
+
+## Administration
+
+Users can be given admin priviledges by accessing the monitor MongoDB and setting ```admin: true``` on the intended user document. These users have unrestricted access to all monitor resources, like servers, builds, and deployments. Additionally, only these users can update other (non-admin) user's permissions on resources, an action not available to regular users even with **Update** level permissions.
+
+Monitor admins are responsible for managing user accounts as well. When a user logs into monitor for the first time, they will not immediately be granted access. An admin must first **enable** the user, which can be done from the 'manage users' page (found in the user dropdown menu in the topbar). Users can also be **disabled** by an admin at any time, which blocks all their access to the GUI and API. 
+
+Users also have some configurable global permissions, these are:
+
+ - create server permission
+ - create build permission
+
+Only users with these permissions (as well as admins) can add additional servers to monitor, and can create additional builds, respectively.

docsite/docusaurus.config.ts

@@ -0,0 +1,98 @@
+import {themes as prismThemes} from 'prism-react-renderer';
+import type {Config} from '@docusaurus/types';
+import type * as Preset from '@docusaurus/preset-classic';
+
+const config: Config = {
+  title: "monitor",
+  tagline: "distributed build and deployment system",
+  favicon: "img/favicon.ico",
+
+  // Set the production url of your site here
+  url: "https://mbecker20.github.io",
+  // Set the /<baseUrl>/ pathname under which your site is served
+  // For GitHub pages deployment, it is often '/<projectName>/'
+  baseUrl: "/monitor/",
+
+  // GitHub pages deployment config.
+  // If you aren't using GitHub pages, you don't need these.
+  organizationName: "mbecker20", // Usually your GitHub org/user name.
+  projectName: "monitor", // Usually your repo name.
+  trailingSlash: false,
+  deploymentBranch: "gh-pages-docs",
+
+  onBrokenLinks: "throw",
+  onBrokenMarkdownLinks: "warn",
+
+  // Even if you don't use internationalization, you can use this field to set
+  // useful metadata like html lang. For example, if your site is Chinese, you
+  // may want to replace "en" with "zh-Hans".
+  i18n: {
+    defaultLocale: "en",
+    locales: ["en"],
+  },
+
+  presets: [
+    [
+      "classic",
+      {
+        docs: {
+          sidebarPath: "./sidebars.ts",
+          // Please change this to your repo.
+          // Remove this to remove the "edit this page" links.
+          editUrl:
+            "https://github.com/facebook/docusaurus/tree/main/packages/create-docusaurus/templates/shared/",
+        },
+        blog: {
+          showReadingTime: true,
+          // Please change this to your repo.
+          // Remove this to remove the "edit this page" links.
+          editUrl:
+            "https://github.com/facebook/docusaurus/tree/main/packages/create-docusaurus/templates/shared/",
+        },
+        theme: {
+          customCss: "./src/css/custom.css",
+        },
+      } satisfies Preset.Options,
+    ],
+  ],
+
+  themeConfig: {
+    // Replace with your project's social card
+    image: "img/monitor-lizard.png",
+    docs: {
+      sidebar: {
+        autoCollapseCategories: true,
+      },
+    },
+    navbar: {
+      title: "monitor",
+      logo: {
+        alt: "monitor lizard",
+        src: "img/monitor-lizard.png",
+      },
+      items: [
+        {
+          type: "docSidebar",
+          sidebarId: "docs",
+          position: "left",
+          label: "docs",
+        },
+        {
+          href: "https://github.com/mbecker20/monitor",
+          label: "GitHub",
+          position: "right",
+        },
+      ],
+    },
+    footer: {
+      style: "dark",
+      copyright: `Built with Docusaurus`,
+    },
+    prism: {
+      theme: prismThemes.github,
+      darkTheme: prismThemes.dracula,
+    },
+  } satisfies Preset.ThemeConfig,
+};
+
+export default config;

docsite/package.json

@@ -0,0 +1,47 @@
+{
+  "name": "docsite",
+  "version": "0.0.0",
+  "private": true,
+  "scripts": {
+    "docusaurus": "docusaurus",
+    "start": "docusaurus start",
+    "build": "docusaurus build",
+    "swizzle": "docusaurus swizzle",
+    "deploy": "docusaurus deploy",
+    "clear": "docusaurus clear",
+    "serve": "docusaurus serve",
+    "write-translations": "docusaurus write-translations",
+    "write-heading-ids": "docusaurus write-heading-ids",
+    "typecheck": "tsc"
+  },
+  "dependencies": {
+    "@docusaurus/core": "3.3.0",
+    "@docusaurus/preset-classic": "3.3.0",
+    "@mdx-js/react": "^3.0.0",
+    "clsx": "^2.0.0",
+    "prism-react-renderer": "^2.3.0",
+    "react": "^18.0.0",
+    "react-dom": "^18.0.0"
+  },
+  "devDependencies": {
+    "@docusaurus/module-type-aliases": "3.3.0",
+    "@docusaurus/tsconfig": "3.3.0",
+    "@docusaurus/types": "3.3.0",
+    "typescript": "~5.2.2"
+  },
+  "browserslist": {
+    "production": [
+      ">0.5%",
+      "not dead",
+      "not op_mini all"
+    ],
+    "development": [
+      "last 3 chrome version",
+      "last 3 firefox version",
+      "last 5 safari version"
+    ]
+  },
+  "engines": {
+    "node": ">=18.0"
+  }
+}

docsite/sidebars.ts

@@ -0,0 +1,62 @@
+import type {SidebarsConfig} from '@docusaurus/plugin-content-docs';
+
+/**
+ * Creating a sidebar enables you to:
+ - create an ordered group of docs
+ - render a sidebar for each doc of that group
+ - provide next/previous navigation
+
+ The sidebars can be generated from the filesystem, or explicitly defined here.
+
+ Create as many sidebars as you want.
+ */
+const sidebars: SidebarsConfig = {
+  docs: [
+    "intro",
+    "core-setup",
+    {
+      type: "category",
+      label: "connecting servers",
+      link: {
+        type: "doc",
+        id: "connecting-servers/index",
+      },
+      items: [
+        "connecting-servers/setup-periphery",
+        "connecting-servers/add-server",
+      ],
+    },
+    {
+      type: "category",
+      label: "build images",
+      link: {
+        type: "doc",
+        id: "build-images/index",
+      },
+      items: [
+        "build-images/configuration",
+        "build-images/pre-build",
+        "build-images/choosing-builder",
+        "build-images/versioning",
+      ],
+    },
+    {
+      type: "category",
+      label: "deploy containers",
+      link: {
+        type: "doc",
+        id: "deploy-containers/index",
+      },
+      items: [
+        "deploy-containers/configuration",
+        "deploy-containers/lifetime-management",
+        // "deploy-containers/choosing-builder",
+        // "deploy-containers/versioning",
+      ],
+    },
+    "permissioning",
+    "file-paths",
+  ],
+};
+
+export default sidebars;

docsite/src/components/Divider.tsx

@@ -0,0 +1,15 @@
+import React from "react";
+
+export default function Divider() {
+  return (
+    <div
+      style={{
+        opacity: 0.7,
+        backgroundColor: "rgb(175, 175, 175)",
+        height: "3px",
+        width: "100%",
+        margin: "75px 0px",
+      }}
+    />
+  );
+}

docsite/src/components/HomepageFeatures/index.tsx

@@ -0,0 +1,58 @@
+import clsx from 'clsx';
+import Heading from '@theme/Heading';
+import styles from './styles.module.css';
+
+type FeatureItem = {
+  title: string;
+  description: JSX.Element;
+};
+
+const FeatureList: FeatureItem[] = [
+  {
+    title: "automated builds 🛠️",
+    description: (
+      <>
+        build auto versioned docker images from github repos, trigger builds on
+        git push
+      </>
+    ),
+  },
+  {
+    title: "deploy docker containers 🚀",
+    description: (
+      <>
+        deploy your builds (or any docker image), see uptime and logs across all
+        your servers
+      </>
+    ),
+  },
+  {
+    title: "powered by Rust 🦀",
+    description: <>The core API and periphery client are written in Rust</>,
+  },
+];
+
+function Feature({title, description}: FeatureItem) {
+  return (
+    <div className={clsx('col col--4')}>
+      <div className="text--center padding-horiz--md">
+        <Heading as="h3">{title}</Heading>
+        <p>{description}</p>
+      </div>
+    </div>
+  );
+}
+
+export default function HomepageFeatures(): JSX.Element {
+  return (
+    <section className={styles.features}>
+      <div className="container">
+        <div className="row">
+          {FeatureList.map((props, idx) => (
+            <Feature key={idx} {...props} />
+          ))}
+        </div>
+      </div>
+    </section>
+  );
+}

docsite/src/components/HomepageFeatures/styles.module.css

@@ -0,0 +1,11 @@
+.features {
+  display: flex;
+  align-items: center;
+  padding: 4rem 0;
+  width: 100%;
+}
+
+.featureSvg {
+  height: 200px;
+  width: 200px;
+}

docsite/src/components/MonitorLogo.tsx

@@ -0,0 +1,11 @@
+import React from "react";
+
+export default function MonitorLogo({ width = "4rem" }) {
+  return (
+    <img
+      style={{ width, height: "auto", opacity: 0.7 }}
+      src="img/monitor-lizard.png"
+      alt="monitor-lizard"
+    />
+  );
+}

docsite/src/components/SummaryImg.tsx

@@ -0,0 +1,13 @@
+import React from "react";
+
+export default function SummaryImg() {
+	return (
+    <div style={{ display: "flex", justifyContent: "center" }}>
+      <img
+        style={{ marginBottom: "4rem", width: "1000px" }}
+        src="img/monitor-summary.png"
+        alt="monitor-summary"
+      />
+    </div>
+  );
+}

docsite/src/css/custom.css

@@ -0,0 +1,30 @@
+/**
+ * Any CSS included here will be global. The classic template
+ * bundles Infima by default. Infima is a CSS framework designed to
+ * work well for content-centric websites.
+ */
+
+/* You can override the default Infima variables here. */
+:root {
+  --ifm-color-primary: #2e8555;
+  --ifm-color-primary-dark: #29784c;
+  --ifm-color-primary-darker: #277148;
+  --ifm-color-primary-darkest: #205d3b;
+  --ifm-color-primary-light: #33925d;
+  --ifm-color-primary-lighter: #359962;
+  --ifm-color-primary-lightest: #3cad6e;
+  --ifm-code-font-size: 95%;
+  --docusaurus-highlighted-code-line-bg: rgba(0, 0, 0, 0.1);
+}
+
+/* For readability concerns, you should choose a lighter palette in dark mode. */
+[data-theme='dark'] {
+  --ifm-color-primary: #25c2a0;
+  --ifm-color-primary-dark: #21af90;
+  --ifm-color-primary-darker: #1fa588;
+  --ifm-color-primary-darkest: #1a8870;
+  --ifm-color-primary-light: #29d5b0;
+  --ifm-color-primary-lighter: #32d8b4;
+  --ifm-color-primary-lightest: #4fddbf;
+  --docusaurus-highlighted-code-line-bg: rgba(0, 0, 0, 0.3);
+}

docsite/src/pages/index.module.css

@@ -0,0 +1,24 @@
+/**
+ * CSS files with the .module.css suffix will be treated as CSS modules
+ * and scoped locally.
+ */
+
+.heroBanner {
+  padding: 4rem 0;
+  text-align: center;
+  position: relative;
+  overflow: hidden;
+}
+
+@media screen and (max-width: 996px) {
+  .heroBanner {
+    padding: 2rem;
+  }
+}
+
+.buttons {
+  display: grid;
+  gap: 1rem;
+  grid-template-columns: 1fr 1fr;
+  width: fit-content;
+}

docsite/src/pages/index.tsx

@@ -0,0 +1,72 @@
+import clsx from 'clsx';
+import Link from '@docusaurus/Link';
+import useDocusaurusContext from '@docusaurus/useDocusaurusContext';
+import Layout from '@theme/Layout';
+import HomepageFeatures from '@site/src/components/HomepageFeatures';
+
+import styles from './index.module.css';
+import MonitorLogo from '../components/MonitorLogo';
+
+function HomepageHeader() {
+  const {siteConfig} = useDocusaurusContext();
+  return (
+    <header className={clsx("hero hero--primary", styles.heroBanner)}>
+      <div className="container">
+        <div style={{ display: "flex", gap: "1rem", justifyContent: "center" }}>
+          <div style={{ position: "relative" }}>
+            <MonitorLogo width="600px" />
+            <h1
+              className="hero__title"
+              style={{
+                margin: 0,
+                position: "absolute",
+                top: "40%",
+                left: "50%",
+                transform: "translate(-50%, -50%)",
+              }}
+            >
+              monitor
+            </h1>
+          </div>
+        </div>
+        <p className="hero__subtitle">{siteConfig.tagline}</p>
+        <div style={{ display: "flex", justifyContent: "center" }}>
+          <div className={styles.buttons}>
+            <Link className="button button--secondary button--lg" to="/docs/intro">
+              docs
+            </Link>
+            <Link
+              className="button button--secondary button--lg"
+              to="https://github.com/mbecker20/monitor"
+            >
+              github
+            </Link>
+            <Link
+              className="button button--secondary button--lg"
+              to="https://github.com/mbecker20/monitor#readme"
+              style={{
+                width: "100%",
+                boxSizing: "border-box",
+                gridColumn: "span 2",
+              }}
+            >
+              screenshots
+            </Link>
+          </div>
+        </div>
+      </div>
+    </header>
+  );
+}
+
+export default function Home(): JSX.Element {
+  const {siteConfig} = useDocusaurusContext();
+  return (
+    <Layout title="monitor docs" description={siteConfig.tagline}>
+      <HomepageHeader />
+      <main>
+        <HomepageFeatures />
+      </main>
+    </Layout>
+  );
+}

docsite/tsconfig.json

@@ -0,0 +1,7 @@
+{
+  // This file is not used in compilation. It is here just for a nice editor experience.
+  "extends": "@docusaurus/tsconfig",
+  "compilerOptions": {
+    "baseUrl": "."
+  }
+}

runfile.toml

@@ -20,4 +20,8 @@ path = "bin/monrun"
 cmd = "cargo run -- sync"
 
 [doc-dev-server]
-cmd = "cargo watch -s 'cargo doc --no-deps -p monitor_client' & http --quiet target/doc"
+cmd = "cargo watch -s 'cargo doc --no-deps -p monitor_client' & http --quiet target/doc"
+
+[docsite-start]
+path = "docsite"
+cmd = "yarn start"