docsite

Cargo.lock

@@ -32,7 +32,7 @@ dependencies = [
 
 [[package]]
 name = "alert_logger"
-version = "1.0.0"
+version = "1.1.0"
 dependencies = [
  "anyhow",
  "axum 0.7.5",
@@ -2017,7 +2017,7 @@ checksum = "b5e6163cb8c49088c2c36f57875e58ccd8c87c7427f7fbd50ea6710b2f3f2e8f"
 
 [[package]]
 name = "logger"
-version = "1.0.0"
+version = "1.1.0"
 dependencies = [
  "anyhow",
  "monitor_client",
@@ -2094,7 +2094,7 @@ dependencies = [
 
 [[package]]
 name = "migrator"
-version = "1.0.0"
+version = "1.1.0"
 dependencies = [
  "anyhow",
  "chrono",
@@ -2220,9 +2220,27 @@ dependencies = [
  "zstd",
 ]
 
+[[package]]
+name = "monitor_cli"
+version = "1.1.0"
+dependencies = [
+ "anyhow",
+ "clap",
+ "colored",
+ "futures",
+ "monitor_client",
+ "partial_derive2",
+ "serde",
+ "strum 0.26.2",
+ "tokio",
+ "toml",
+ "tracing",
+ "tracing-subscriber",
+]
+
 [[package]]
 name = "monitor_client"
-version = "1.0.0"
+version = "1.1.0"
 dependencies = [
  "anyhow",
  "async_timing_util",
@@ -2254,7 +2272,7 @@ dependencies = [
 
 [[package]]
 name = "monitor_core"
-version = "1.0.0"
+version = "1.1.0"
 dependencies = [
  "anyhow",
  "async-recursion",
@@ -2301,7 +2319,7 @@ dependencies = [
 
 [[package]]
 name = "monitor_periphery"
-version = "1.0.0"
+version = "1.1.0"
 dependencies = [
  "anyhow",
  "async-trait",
@@ -2332,7 +2350,7 @@ dependencies = [
 
 [[package]]
 name = "monitor_sync"
-version = "1.0.0"
+version = "1.1.0"
 dependencies = [
  "anyhow",
  "clap",
@@ -2343,24 +2361,6 @@ dependencies = [
  "tokio",
 ]
 
-[[package]]
-name = "monrun"
-version = "1.0.0"
-dependencies = [
- "anyhow",
- "clap",
- "colored",
- "futures",
- "monitor_client",
- "partial_derive2",
- "serde",
- "strum 0.26.2",
- "tokio",
- "toml",
- "tracing",
- "tracing-subscriber",
-]
-
 [[package]]
 name = "mungos"
 version = "0.5.4"
@@ -2661,7 +2661,7 @@ checksum = "9b2a4787296e9989611394c33f193f676704af1686e70b8f8033ab5ba9a35a94"
 
 [[package]]
 name = "periphery_client"
-version = "1.0.0"
+version = "1.1.0"
 dependencies = [
  "anyhow",
  "monitor_client",
@@ -3660,7 +3660,7 @@ dependencies = [
 
 [[package]]
 name = "tests"
-version = "1.0.0"
+version = "1.1.0"
 dependencies = [
  "anyhow",
  "dotenv",
@@ -4216,7 +4216,7 @@ checksum = "8ecb6da28b8a351d773b68d5825ac39017e680750f980f3a1a85cd8dd28a47c1"
 
 [[package]]
 name = "update_logger"
-version = "1.0.0"
+version = "1.1.0"
 dependencies = [
  "anyhow",
  "logger",

Cargo.toml

@@ -3,7 +3,7 @@ resolver = "2"
 members = ["bin/*", "lib/*", "client/core/rs", "client/periphery/rs"]
 
 [workspace.package]
-version = "1.0.0"
+version = "1.1.0"
 edition = "2021"
 authors = ["mbecker20 <becker.maxh@gmail.com>"]
 license = "GPL-3.0-or-later"

bin/cli/Cargo.toml

@@ -1,10 +1,15 @@
 [package]
-name = "monrun"
+name = "monitor_cli"
+description = "Command line tool to sync monitor resources and execute file defined procedures"
 version.workspace = true
 edition.workspace = true
 authors.workspace = true
 license.workspace = true
 
+[[bin]]
+name = "monitor"
+path = "src/main.rs"
+
 # See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
 
 [dependencies]

bin/cli/README.md

@@ -0,0 +1,21 @@
+# monitor CLI
+
+Monitor CLI is a command line tool to sync monitor resources and execute file defined procedures.
+
+## Examples
+
+```sh
+## Sync resources in a single file
+monitor sync ./resources/deployments.toml
+
+## Sync resources gathered across multiple files in a directory
+monitor sync ./resources
+
+## Path defaults to './resources', in this case you can just use:
+monitor sync
+```
+
+```sh
+## Execute a TOML defined procedure
+monitor exec ./execution/execution.toml
+```

bin/cli/resources/deployments.toml

@@ -104,7 +104,7 @@ tags = ["logging"]
 server_id = "monitor-01"
 network = "host"
 restart = "unless-stopped"
-process_args = "-server.http-listen-port=3200 -server.grpc-listen-port=9096 --storage.trace.backend=local --storage.trace.local.path=/tmp/tempo/traces --storage.trace.wal.path=/tmp/tempo/wal"
+command = "-server.http-listen-port=3200 -server.grpc-listen-port=9096 --storage.trace.backend=local --storage.trace.local.path=/tmp/tempo/traces --storage.trace.wal.path=/tmp/tempo/wal"
 extra_args = ["--user root"]
 
 [deployment.config.image]
@@ -129,7 +129,7 @@ tags = ["logging"]
 server_id = "monitor-01"
 network = "host"
 restart = "unless-stopped"
-process_args = "--config /etc/vector/*.toml"
+command = "--config /etc/vector/*.toml"
 extra_args = ["--user root"]
 
 [deployment.config.image]

bin/migrator/src/legacy/v0/deployment.rs

@@ -369,7 +369,7 @@ impl TryFrom<Deployment>
             .collect(),
           network: value.docker_run_args.network,
           restart: value.docker_run_args.restart.into(),
-          process_args: value
+          command: value
             .docker_run_args
             .post_image
             .unwrap_or_default(),

bin/monrun/readme.md

@@ -1,9 +0,0 @@
-## Examples
-
-```sh
-monrun resources up ./resources/prod_hub.toml
-```
-
-```sh
-monrun exec 
-```

bin/periphery/src/helpers/docker/container.rs

@@ -197,7 +197,7 @@ pub async fn deploy(
       return Log::error("docker login", serialize_error_pretty(&e))
     }
   };
-  
+
   if let Err(e) = docker_login(
     &optional_string(&deployment.config.docker_account),
     &docker_token,
@@ -266,7 +266,7 @@ pub fn docker_run_command(
         volumes,
         ports,
         network,
-        process_args,
+        command,
         restart,
         environment,
         labels,
@@ -285,9 +285,9 @@ pub fn docker_run_command(
   let restart = parse_restart(restart);
   let environment = parse_environment(environment);
   let labels = parse_labels(labels);
-  let process_args = parse_process_args(process_args);
+  let command = parse_command(command);
   let extra_args = parse_extra_args(extra_args);
-  format!("docker run -d --name {name}{ports}{volumes}{network}{restart}{environment}{labels}{extra_args} {image}{process_args}")
+  format!("docker run -d --name {name}{ports}{volumes}{network}{restart}{environment}{labels}{extra_args} {image}{command}")
 }
 
 fn parse_conversions(
@@ -321,10 +321,10 @@ fn parse_restart(restart: &RestartMode) -> String {
   format!(" --restart {restart}")
 }
 
-fn parse_process_args(process_args: &String) -> String {
-  if process_args.is_empty() {
+fn parse_command(command: &str) -> String {
+  if command.is_empty() {
     String::new()
   } else {
-    format!(" {process_args}")
+    format!(" {command}")
   }
 }

client/core/rs/Cargo.toml

@@ -1,5 +1,6 @@
 [package]
 name = "monitor_client"
+description = "Client for the monitor build and deployment system"
 version.workspace = true
 edition.workspace = true
 authors.workspace = true

client/core/rs/src/entities/deployment.rs

@@ -128,10 +128,10 @@ pub struct DeploymentConfig {
   /// This is interpolated at the end of the `docker run` command,
   /// which means they are either passed to the containers inner process,
   /// or replaces the container command, depending on use of ENTRYPOINT or CMD in dockerfile.
-  /// Empty is no process args.
+  /// Empty is no command.
   #[serde(default)]
   #[builder(default)]
-  pub process_args: String,
+  pub command: String,
 
   /// Extra args which are interpolated into the `docker run` command,
   /// and affect the container configuration.

client/core/ts/src/types.ts

@@ -200,13 +200,20 @@ export interface Resource<Config, Info> {
 	 * `{ "_id": { "$oid": "..." }, ...(rest of serialized Resource<T>) }`
 	 */
 	_id?: MongoId;
-	/**  */
+	/**
+	 * The resource name.
+	 * This is guaranteed unique among others of the same resource type.
+	 */
 	name: string;
+	/** A description for the resource */
 	description?: string;
+	/** When description last updated */
 	updated_at?: I64;
 	/** Tag Ids */
 	tags?: string[];
+	/** Resource-specific information (not user configurable). */
 	info?: Info;
+	/** Resource-specific configuration. */
 	config: Config;
 }
 
@@ -225,12 +232,15 @@ export type Alerter = Resource<AlerterConfig, AlerterInfo>;
 export type GetAlerterResponse = Alerter;
 
 export interface ResourceListItem<Info> {
+	/** The resource id */
 	id: string;
+	/** The resource type, ie `Server` or `Deployment` */
 	type: ResourceTarget["type"];
+	/** The resource name */
 	name: string;
-	created_at: I64;
 	/** Tag Ids */
 	tags: string[];
+	/** Resource specific info */
 	info: Info;
 }
 
@@ -458,9 +468,9 @@ export interface DeploymentConfig {
 	 * This is interpolated at the end of the `docker run` command,
 	 * which means they are either passed to the containers inner process,
 	 * or replaces the container command, depending on use of ENTRYPOINT or CMD in dockerfile.
-	 * Empty is no process args.
+	 * Empty is no command.
 	 */
-	process_args?: string;
+	command?: string;
 	/**
 	 * Extra args which are interpolated into the `docker run` command,
 	 * and affect the container configuration.

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

@@ -6,4 +6,6 @@ Building on a machine running production software is usually not a great idea, a
 
 ### 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). 
+Builders are now monitor resources, and are managed via the core API / can be updated using the UI.
+To use this feature, you need an ec2 AMI with docker and monitor periphery configured to run on system start.
+Once you create your builder and add the necessary configuration, it will be available to attach to builds.

docsite/docs/build-images/configuration.md

@@ -5,25 +5,28 @@ 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.
+Many repos are private, in this case a Github access token is needed by the building server.
+It can either come from and account defined in the core configuration,
+or in the periphery configuration of the building server.
+These are specified in the config like `username = "access_token"`.
 
 ### 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```
+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```.
+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```. 
+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:
+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 navigating to the `Build Args` tab in the config. 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.
+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

@@ -4,9 +4,11 @@ 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.
+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).
+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';

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

@@ -1,6 +1,9 @@
-# adding the server to monitor
+# adding servers 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```.
+The easiest way to add servers is with the GUI. 
+Navigate to the Servers page, click the New Server button, input the name, and hit create.
+This will navigate to the created server, where you can configure it's address.
+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.
 

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

@@ -1,12 +1,12 @@
 # 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.
+The easiest way to setup periphery is to use the [Periphery setup script](https://github.com/mbecker20/monitor/tree/main/scripts).
 
 ### 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.
+ 2. Create and edit your config files, following the [config example](https://github.com/mbecker20/monitor/blob/main/config_example/periphery.config.example.toml).
 
  3. Ensure that inbound connectivity is allowed on the port specified in periphery.config.toml (default 8000).
 
@@ -22,22 +22,21 @@ periphery \
 	--config-path /other_path/to/overide-periphery-config-directory \
 	--config-keyword periphery \
 	--config-keyword config \
-	--merge-nested-config \
-	--home_dir /home/username
+	--merge-nested-config
 ```
 
 ### passing config files
 
-Either file paths or directory paths can be passed to ```--config-path```.
+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 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```.
+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. 
+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. 
+`--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.
+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

@@ -8,7 +8,7 @@ setting up monitor core is fairly simple. there are some requirements to run mon
 
 ## 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.
+create a configuration file on the system, for example at `~/.config/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, 
@@ -18,6 +18,11 @@ 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.
 :::
 
+:::note
+all configuration can additionally be passed using environment variables, which override the value in the config file.
+see ###CONFIG_RUST_DOCS###.
+:::
+
 ## 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).

docsite/docs/deploy-containers/configuration.md

@@ -12,7 +12,7 @@ By default, monitor will deploy the latest available version of the build, or yo
 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```.
+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.
 
@@ -20,7 +20,7 @@ If the image repository is private, you can select an available docker account t
 
 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.
+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:
 
@@ -28,9 +28,9 @@ If you do select select a network other than host, you can specify port bindings
 27018 : 27017
 ```
 
-In this case, you would access mongo from outside of the container on port ```27018```.
+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.
+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
 
@@ -38,7 +38,8 @@ Docker, like systemd, has a couple options for handling when a container exits.
 
 ## 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.
+Monitor enables you to easily manage environment variables passed to the container. 
+In the GUI, navigate to the environment tab of the configuration on the deployment page.
 
 You pass environment variables just as you would with a ```.env``` file:
 
@@ -72,12 +73,12 @@ Not all features of docker are mapped directly by monitor, only the most common.
 --log-opt max-file=3
 ```
 
-## post image
+## command
 
-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:
+Sometimes you need to override the default command in the image, or 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'.
+In order to achieve this with monitor, just pass `--quiet` to 'command'.

docsite/docs/deploy-containers/index.mdx

@@ -1,6 +1,8 @@
 # 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.
+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).
 

docsite/docs/file-paths.md

@@ -18,9 +18,9 @@ The one exception is the Dockerfile path, which is given relative to the build d
 
 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.
+ 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
 
@@ -28,4 +28,4 @@ relative file paths are joined with the path of the repo on the system using a R
 
 ## 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```.
+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

@@ -4,11 +4,11 @@ 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.
+If you have many servers running many applications, it can be a challenge to keep things organized and easily accessible. Monitor is a web app to provide structure for managing your servers, builds, deployments, and automated procedures.
 
 ## 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 is opinionated by design, and uses [docker](https://docs.docker.com/) as the container engine for building and deploying.
 
 ## monitor
 
@@ -16,9 +16,9 @@ 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.
+ 3. Manage repositories on remote servers.
+ 4. Keep a record of all the actions that are performed and by whom.
+ 5. View realtime and historical system resource usage, and alert for out of bounds values.
 
 ## architecture and components
 
@@ -30,9 +30,6 @@ The core is a web server that hosts the core API and serves the frontend to be a
 ### 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. 

docsite/docs/permissioning.md

@@ -12,7 +12,7 @@ There are 4 levels of permissions a user can have on a resource:
 
  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.
+ 4. **Write**. The user has full access to the resource, they can execute any actions, update the configuration, and delete the resource.
 
 ## Administration
 

frontend/src/components/resources/deployment/config/index.tsx

@@ -97,13 +97,13 @@ export const DeploymentConfig = ({ id }: { id: string }) => {
                 disabled={disabled}
               />
             ),
-            process_args: (value, set) => (
-              <ConfigItem label="Process Args">
+            command: (value, set) => (
+              <ConfigItem label="Command">
                 <TextUpdateMenu
-                  title="Update Process Args"
-                  placeholder="Set Process Args"
+                  title="Update Command"
+                  placeholder="Set Command"
                   value={value}
-                  onUpdate={(process_args) => set({ process_args })}
+                  onUpdate={(command) => set({ command })}
                   triggerClassName="min-w-[300px] max-w-[400px]"
                 />
               </ConfigItem>