diff --git a/Chart.yaml b/Chart.yaml
index 61329e1..36ef8f1 100644
--- a/Chart.yaml
+++ b/Chart.yaml
@@ -10,7 +10,7 @@ description: |-
   the high alpine areas of the Andes and a relative of the llama.
 annotations:
   category: TaskTracker
-version: 0.3.0
+version: 0.3.1
 appVersion: 0.21.0
 kubeVersion: ">= 1.19"
 dependencies:
diff --git a/README.md b/README.md
index 8e8ebc0..9e3e0d4 100644
--- a/README.md
+++ b/README.md
@@ -39,9 +39,71 @@ api:
       enabled: true
       accessMode: ReadWriteOnce
       size: 10Gi
+      mountPath: /app/vikunja/files
       storageClass: storage-class
 ```
 
+### Utilizing environment variables from Kubernetes secrets
+
+Each environment variable that is "injected" into a pod can be sourced from a Kubernetes secret. This is useful when you wish to add values that you would rather keep as secrets in your GitOps repo, as environment variables in the pods.
+
+Assuming that you had a Kubernetes secret named `vikunja-env`, this is how you would add the value stored at key `VIKUNJA_DATABASE_PASSWORD` as the environment variable named `VIKUNJA_DATABASE_PASSWORD`:
+
+```yaml
+api:
+  env:
+    VIKUNJA_DATABASE_PASSWORD:
+      valueFrom:
+        secretKeyRef:
+          name: vikunja-env
+          key: VIKUNJA_DATABASE_PASSWORD
+    VIKUNJA_DATABASE_USERNAME: "db-user"
+```
+
+Alternatively, instead of defining each and every key, if the keys within the secret are the names of environment variables, you could also do the following:
+
+```yaml
+api:
+  envFrom:
+    - secretRef:
+      name: vikunja-secret-env
+  env:
+    VIKUNJA_DATABASE_USERNAME: "db-user"
+```
+
+This will add all keys within the Kubernetes secret named `vikunja-secret-env` as environment variables to the `api` pod. Additionally, if you did not have the key `VIKUNJA_DATABASE_USERNAME` in the `vikunja-secret-env` secret, you could still define it as an environment variable seen above.
+
+How the `envFrom` key works can be seen [here](https://github.com/bjw-s/helm-charts/blob/a081de53024d8328d1ae9ff7e4f6bc500b0f3a29/charts/library/common/values.yaml#L155).
+
+### Utilizing a Kubernetes secret as the `config.yml` file instead of a ConfigMap
+
+If you did not wish to use the ConfigMap provided by the chart, and instead wished to mount your own Kubernetes secret as the `config.yml` file in the `api` pod, you could provide values such as the following (assuming `asdf-my-custom-secret1` was the name of the secret that had the `config.yml` file):
+
+```yaml
+api:
+  persistence:
+    config:
+      type: secret
+      name: asdf-my-custom-secret1
+```
+
+Then your secret should look something like the following so that it will mount properly:
+
+```yaml
+apiVersion: v1
+kind: Secret
+metadata:
+  name: asdf-my-custom-secret1
+  namespace: vikunja
+type: Opaque
+stringData:
+  config.yml: |
+    key1: value1
+    key2: value2
+    key3: value3
+
+```
+
 ### Modifying Deployed Resources
 
 Often times, modifications need to be made to a Helm chart to allow it to operate in your Kubernetes cluster. By utilizing bjw-s's `common` library, there are quite a few options that can be easily modified.
diff --git a/values.yaml b/values.yaml
index 3e410b8..4a084b1 100644
--- a/values.yaml
+++ b/values.yaml
@@ -25,6 +25,7 @@ api:
       # existingClaim: # your-claim
       accessMode: ReadWriteOnce
       size: 10Gi
+      mountPath: /app/vikunja/files
       # storageClass: storage-class
   ingress:
     main: