docs: started rewriting everything

docs/content/usage/_index.md

@@ -0,0 +1,17 @@
+# Usage
+
+Vieter is distributed as a swiss army knife-style binary, meaning all of its
+components are compiled into a single binary. These various components can then
+be used by passing the correct CLI arguments to the binary.
+
+Each of these components requires some configuration variables, a thorough
+explanation of this can be found over at the [Configuration](/configuration)
+page.
+
+## Components
+
+Currently, the binary consists of the following components:
+
+* [Server](server)
+* [Cron](cron)
+* [Repos CLI](repos-cli)

docs/content/usage/server.md

@@ -0,0 +1,50 @@
+---
+weight: 10
+---
+
+# Server
+
+The server is the implementation of the repository.
+
+```sh
+vieter server
+```
+
+starts the HTTP server. Its endpoints are listed [here](/api).
+
+## Multiple repositories
+
+Vieter can contain multiple repositories, each of which is further divided into
+various architectures.
+
+A repository is created once a package archive is published to it using [this
+route](/api#post-repopublish):
+
+```sh
+curl -XPOST -H "X-API-KEY: your-key" -T some-package.pkg.tar.zst https://example.com/somerepo/publish
+```
+
+This repository can then be added to Pacman as
+described below.
+
+## Pacman
+
+A Vieter repository can be added to Pacman like any other repository. In your
+`/etc/pacman.conf` file, add the following lines:
+
+```
+[vieter]
+Server = https://example.com/$repo/$arch
+SigLevel = Optional
+```
+
+Here, you see two important placeholder variables which get replaced by Pacman
+when reading the file. `$repo` is replaced by the name within the square
+brackets, which in this case would be `vieter`. `$arch` is replaced by the
+output of `uname -m`. Because Vieter supports multiple repositories &
+architectures per repository, using this notation makes sure you always use the
+correct endpoint for fetching files.
+
+I recommend placing this below all other repository entries, as the order
+decides which repository gets used if there's ever a naming conflict.
+

docs/content/usage/usage.md

@@ -0,0 +1,54 @@
+---
+weight: 30
+---
+# Usage
+
+## Starting the server
+
+To start a server, either install it using Docker (see
+[Installation](/installation)) or run it locally by executing `vieter
+server`. See [Configuration](/configuration) for more information about
+configuring the binary.
+
+## Multiple repositories
+
+Vieter works with multiple repositories. This means that a single Vieter server
+can serve multiple repositories in Pacman. It also automatically divides files
+with specific architectures among arch-repos. Arch-repos are the actual
+repositories you add to your `/etc/pacman.conf` file. See [Configuring
+Pacman](/usage#configuring-pacman) below for more info.
+
+## Adding packages
+
+Using Vieter is currently very simple. If you wish to add a package to Vieter,
+build it using makepkg & POST that file to the `/<repo>/publish` endpoint of
+your server. This will add the package to the repository. Authentification
+requires you to add the API key as the `X-Api-Key` header.
+
+All of this can be combined into a simple cURL call:
+
+```
+curl -XPOST -H "X-API-KEY: your-key" -T some-package.pkg.tar.zst https://example.com/somerepo/publish
+```
+
+`somerepo` is automatically created if it doesn't exist yet.
+
+## Configuring Pacman
+
+Configuring Pacman to use a Vieter instance is very simple. In your
+`/etc/pacman.conf` file, add the following lines:
+
+```
+[vieter]
+Server = https://example.com/$repo/$arch
+SigLevel = Optional
+```
+
+Here, you see two important placeholder variables. `$repo` is replaced by the
+name within the square brackets, which in this case would be `vieter`. `$arch`
+is replaced by the output of `uname -m`. Because Vieter supports multiple
+repositories & architectures per repository, using this notation makes sure you
+always use the correct endpoint for fetching files.
+
+I recommend placing this below all other repository entries, as the order
+decides which repository should be used if there's ever a naming conflict.