initial post

.gitea/workflows/build-and-push-image.yaml

@@ -24,7 +24,7 @@ jobs:
       - name: ⚙️ Setup Hugo
         uses: peaceiris/actions-hugo@v3
         with:
-          hugo-version: '0.148.1'
+          hugo-version: '0.161.1'
           extended: true
 
       - name: 🏗️ Build Hugo site

container/site/content/posts/2026-01-06-replace-thermostat-housing/index.md

@@ -0,0 +1,67 @@
++++
+categories = ["vehicle"]
+date = 2026-01-06T16:00:00Z
+description = ""
+draft = false
+slug = "2026-01-06-replace-thermostat"
+title = "🌡️ Replacing Thermostat Housing Assembly"
+author = "nicholas"
++++
+
+The engine coolant temperature gauge reports temperatures that are too low. The engine never reaches the proper operating temperature. The cabin air heating system produces only slightly hotter-than-ambient air. The upper radiator hose begins to warm immediately on starting the car. These are all symptoms of a thermostat that is stuck in the open position. I bought a new one from automotive store.
+
+
+## 🛠️ Parts and equipment
+I need a few tools and the replacement part:
+
+- Murray Plus 221 Degree Thermostat Housing - 73021
+- car ramp (2)
+- wheel chocks (2)
+- torx E10 socket
+- torx T15 drive bit
+- hex 10mm socket
+- flat head screwdriver
+- phillips head screwdriver
+- ratchet
+- clamp pliers
+- hook pick
+- drain pan
+- DEX-COOL engine coolant
+- automotive trim removal tool
+- silicone tube (3/8 in ID)
+
+{{< image 
+    src="images/oreilly-thermostat-part.png" 
+    caption="Thermostat Housing Assembly" >}}
+
+
+## ⚙️ Process
+I need to drain the coolant system first, then I can replace the thermostat, and finally refill the coolant.
+
+
+{{< image 
+    src="images/coolant-system-diagram-original.png" 
+    caption="Coolant System Diagram" >}}
+
+### drain coolant system
+- place car onto ramp, place wheel chocks under rear wheels
+- remove negative battery terminal clamp, disconnect
+- remove engine splash shield
+- place silicone drain hose over petcock nipple, place catch pan under hose
+- unscrew coolant reservoir cap
+- open petcock valve, drain coolant
+- close petcock valve, remove tube, store used coolant
+- replace splash shield
+
+### replace thermostat housing assembly
+- remove air filter hose
+- remove positive crank ventilation hose
+- remove sensor connector
+- remove upper radiator hose
+- remove thermostat housing assembly
+- install replacement thermostat housing assembly
+- replace all removed components
+
+I refill with new coolant and purge the coolant system of air.
+
+✅ Done.

container/site/content/posts/2026-01-22-server-top/index.md

@@ -0,0 +1,33 @@
++++
+categories = ["build"]
+date = 2026-01-22T20:00:00Z
+description = ""
+draft = false
+slug = "2026-01-22-server-top"
+title = "🔝 Server Top"
+author = "nicholas"
++++
+
+I used a piece of plywood to cover the void of the server rack. Its purpose is to enable me to place things atop it. I must remind myself of this singular purpose to cope with its ugliness.
+
+The stain looked great, then I completely ruined the look by encasing it in a thick layer of polyurethane plastic. Now it has a wet-looking orange glow to it, and probably sheds a trillion microplastic particles into the air each day. I am a little ashamed of the decision, but life goes on and the finish is totally inconsequential to the tabletop's stated purpose.
+
+I picked out a nice-looking piece at Home Depot, and had someone cut it to size for me. Then I sanded the edges to give them each a small radius, sanded the surface, vacuumed and wiped it totally clean for staining. But then I found some leftover PU and some painting pyramids and thought "why not"? I placed the plywood on top of the pyramids and slapped on several layers of way-too-thick oil-based PU with a PU foam brush. It was old and partially cured PU, impossible to apply in thin coats and hard to handle, but it did not stop me and probably should have.
+
+---
+
+{{< image 
+    src="images/server-top-raw.jpg" 
+    caption="Plywood cut to size" >}}
+
+{{< image 
+    src="images/server-top-stained.jpg" 
+    caption="Plywood stained" >}}
+
+{{< image 
+    src="images/server-top-complete.JPG" 
+    caption="Finished top" >}}
+
+I am not totally unhappy with result but I could have done better. The look is competitive with the default raw, dull yellow surface finish at least. 👍
+
+✅ Done.

container/site/content/posts/2026-03-01-voip/index.md

@@ -0,0 +1,167 @@
++++
+categories = ["software"]
+tags = ["freepbx","vm","bulkvs","sip","voip"]
+date = 2026-03-01T08:00:00Z
+description = ""
+draft = false
+slug = "2026-03-01-voip"
+title = "☎️ VoIP"
+author = "nicholas"
++++
+
+I pay my share of the family phone plan ($15/mo), and in return I get unlimited texts, 1000 minutes of calls, and 1 GB of data. This is already extraordinarily cheap, but for how little I use the service I think I can do better, at least in terms of raw cost of owning a phone number on which I can make and receive voice calls. I can get the cost down to pennies a month, depending on how much time I spend in a phone call. 
+
+I do not actually intend to use this as my primary phone number, **this is just for fun**.
+
+
+{{< image
+    src="images/bulkvs-rates.png"
+    caption="BulkVS Rates" >}}
+
+
+As usual, my thriftiness comes at high cost:
+- I must have an internet connection to make and receive calls.
+- Poor audio quality: I will be limited to narrowband audio, since my SIP trunk/carrier (BulkVS) does not support wideband audio. 
+
+## ℹ️ Overview
+I need a few pieces to make this work: a PBX (FreePBX on Debian), a SIP trunk/carrier (BulkVS), and a VoIP phone or softphone (MicroSIP, Linphone).
+
+**PBX**
+
+The PBX is the phone system. I run it on a small VM with FreePBX installed. It answers incoming calls, sends calls to extensions, applies inbound and outbound routes, manages voicemail, and gives SIP phones or softphones a place to register. In my setup, the PBX is the part I control. 
+
+**SIP Trunk**
+
+The SIP trunk/carrier is the bridge to the public phone network. I use BulkVS for this. BulkVS gives me a DID, which is the phone number people call, and a SIP trunk, which is the connection FreePBX uses to send and receive calls. In this setup, BulkVS is the part that connects my FreePBX server to normal phone numbers.
+
+**Softphone**
+
+The VoIP phone or softphone is the device I actually talk through. A hardware VoIP phone would sit on my desk like a normal phone. A softphone is an app, such as MicroSIP on Windows or Linphone on Android. Either way, the phone registers to FreePBX as an extension. 
+
+It needs:
+- FreePBX server address
+- extension number
+- extension's SIP password
+
+The simple version is: callers reach the BulkVS DID, BulkVS sends the call to FreePBX, and FreePBX rings my VoIP phone or softphone. For outbound calls, my phone sends the call to FreePBX, FreePBX sends it to BulkVS, and BulkVS carries it to the public phone network.
+
+## ⚙️ Configuration
+
+### PBX host
+
+The PBX runs as a small Debian 12 VM with FreePBX installed.
+
+- RAM: 2 GiB
+- Disk: 20 GiB
+- Network: static internal IP address
+- Admin: FreePBX web UI initialized
+
+{{< image
+    src="images/proxmox-phonepooter.png"
+    caption="Proxmox VM - Debian + FreePBX" >}}
+
+### Phone extension
+
+I configure FreePBX with one extension for each softphone, e.g.:
+
+- Type: PJSIP extension
+- Extension: `101`
+- Display name: `nicholas-mobile`
+- Secret: strong SIP password, auto-generated in FreePBX
+
+
+{{< image
+    src="images/freepbx-extensions.png"
+    caption="FreePBX SIP extensions" >}}
+
+### Softphone
+
+The softphone registers to FreePBX as the extension.
+
+- App: MicroSIP on Windows or Linphone on Android
+- SIP server or domain: FreePBX server address, e.g. `sip.uuard.com`
+- Username: FreePBX extension number, e.g. `104`
+- Password: extension SIP secret
+
+Once the account is configured, I expect it to be 'registered'
+
+{{< image
+    src="images/microsip-call.png"
+    caption="MicroSIP call success" >}}
+
+
+### BulkVS Configuration
+
+BulkVS provides the phone number and the carrier side of the call path. I can use it to receive calls from the public phone network and send outbound calls from FreePBX.
+
+- Create BulkVS account
+- Fund account for testing: $25 minimum
+- Purchase a DID
+    - **Inbound** > **DIDs - Purchase**.
+- Enable BulkVS services: CNAM, Outbound, Inbound
+    - **Account** > **Service Status**.
+
+{{< image
+    src="images/bulkvs-service-enable.png"
+    caption="bulkvs services enabled" >}}
+
+
+BulkVS is configured to know where my PBX lives and how to deliver calls to it. Next, I configure a host:
+
+- In **Interconnection** > **Hosts**, supply internet-facing IP address of the PBX, e.g. `39.216.21.150`.
+- To create a Trunk Group, go to **Interconnection** > **Trunk Group - Manage**.
+    - Select **Create** for **SIP Registration Trunk Group**.
+        - **Trunk Group Name**: e.g. `bulkvs-trunk`
+        - **Password**: e.g. `1#0LZWxh*B4ax28q`
+        - **Digit Delivery**: 11 Digits
+- In **Inbound** > **DIDs - Manage**, select **view** on the phone number. Select the trunk group `bulkvs-trunk` and save changes.
+
+
+### FreePBX Configuration
+
+FreePBX is configured with a PJSIP trunk that registers to BulkVS.
+
+- Trunk name: `bulkvs-trunk`
+- Type: `PJSIP`
+- Authentication: BulkVS SIP registration username and password
+- SIP server: value from the BulkVS portal, e.g. `sip.bulkvs.com`
+- Registration: enabled with the BulkVS registration settings
+- Match (Permit): BulkVS signaling IP addresses
+- Codecs: `ulaw`, `alaw`
+
+{{< image
+    src="images/freepbx-trunks.png"
+    caption="FreePBX Trunks" >}}
+
+#### Inbound and Outbound routes
+
+**Inbound**
+
+I create an inbound route for the BulkVS DID. Calls to the DID ring at the configured destinations:
+
+- DID: BulkVS number in 11-digit format
+- Destination: extension or ring group
+
+I have configured a ring group containing several extensions. Each extension in the ring group `600` will ring when the configured DID is called.
+
+{{< image
+    src="images/freepbx-inbound-routes.png"
+    caption="FreePBX Ring Groups" >}}
+{{< image
+    src="images/freepbx-ring-groups.png"
+    caption="FreePBX Ring Groups" >}}
+{{< image
+    src="images/freepbx-ring-group-600.png"
+    caption="FreePBX Ring Group 600 Configuration" >}}
+
+**Outbound**
+I also configure an outbound route that sends normal phone-number calls through BulkVS:
+
+- Trunk sequence: `bulkvs-trunk` first
+- Match pattern: `1NXXNXXXXXX`
+- Match pattern: `NXXNXXXXXX`
+- Prepend for `NXXNXXXXXX`: `1`
+
+🎉 **It works!**
+
+✅ Done.

container/site/content/posts/2026-03-31-car-maintenance/_index.md

@@ -1,24 +0,0 @@
-+++
-categories = ["vehicle"]
-date = 2026-03-31T03:58:00-05:00
-description = ""
-draft = false
-slug = "2026-03-31-car-maintenance"
-title = "🚗 Car Issue"
-author = "nicholas"
-+++
-
-Car Issue
-
-## Symptoms
-- Issue begins after refueling
-- Engine sputters/rough idle when stopped (idle, park, red lights)
-- Vehicle lurches while stopped
-- Occurs without pressing gas pedal
-- No sputtering while driving / under throttle
-- Intermittent throttle non-response (pressing gas sometimes has no effect)
-
-## Diagnosing
-
-## Fix
-Replace Vapor Canister Purge Solenoid Valve

container/site/content/posts/2026-05-10-summer-bicycle-eats/index.md

@@ -0,0 +1,21 @@
++++
+categories = ["bicycle","food"]
+date = 2026-05-10T16:00:00Z
+description = ""
+draft = false
+slug = "2026-05-10-summer-bicycle-eats"
+title = "🧺 \"On a bike, you can go anywhere\""
+author = "nicholas"
++++
+
+Basically: bicycling, eating food, nice weather. Good things. Combine = good.
+
+I can enjoy my food in comfort of own home, yes, ok. But time passes too quickly like this and sometimes a new place fixes this, and other latent problems. And why not bring some food to this new place? And why not a new food? Uncious salamis, a pickle or two, a new flavor of carbonated beverage, hamburger sushi, maybe. Two novel experiences, life can only get so interesting. This is all familiar idea which needs no explanation. Outdoor seating at a cafe. Picnics. This is not unusual desire, I think, so reader understands. **And on a bike, you can go anywhere**. With some cargo attachment the food comes along just fine. Why trouble to awaken the 26 year old 4000 pound beast on four wheels just for this? Wrong tool for the job. What about a 20 pound bicycle with a lunch box? Ok, exactly.
+
+I note possible interference from pedal stroke. Mount it, tighten it. It is too easy. I find a cooler matching the inner dimensions of the basket. Perfect match. 12 cans of beverage? Of course.
+
+- `Wald 582 Side-Mount Folding Rear Basket (Silver)`
+- `Ozark Trail 12-Can Soft-Sided Cooler with Removable Hard Liner (Red)`
+
+✅ Done.
+

container/site/content/posts/2026-05-31-plant-repot/index.md

@@ -0,0 +1,66 @@
++++
+categories = ["plants"]
+date = 2026-05-31T10:00:00-06:00
+description = ""
+draft = false
+slug = "2026-05-31-plant-repot"
+title = "🪴 Plant Repotting"
+author = "nicholas"
++++
+
+The plants need new pots more fitting of their beauty and vitality not some ugly slimy plastic. I prefer clay: better aesthetics, drier soil and easier to control pests.
+
+## Ficus Audrey
+
+For two years this tree did nothing. No growth, no changes, nothing at all. So we attempted to induce some kind of growth by snipping off a small length of growth at the top: the **apical meristem**. This shortly prompted the smallest of growths to develop on the node just beneath the cut, barely detectable, a small green nub. 
+
+{{< image 
+    src="images/ficus-audrey-new-growth.jpg"
+    caption="BEFORE: new growth, very early" >}}
+
+And then, once again, for months it was still, unchanging...until a few weeks ago when we noticed the roots had begun to reach out beneath the pot, winding around into the saucers of nearby planters. And the tiny green nub had elongated into a very small proto-leaf. This is all very unremarkable as far as plants go, just part of the normal course of things, but it is the first time since acquiring the plant that it has shown any obvious signs of actually being alive.
+
+{{< image 
+    src="images/ficus-audrey-new-leaf.JPG"
+    caption="AFTER: growth developed into a new leaf" >}}
+
+These signs of expanding life call for an expanded container.
+
+{{< image 
+    src="images/ficus-audrey-new-pot.JPG"
+    caption="ficus audrey repotted" >}}
+
+
+## Pin-stripe calathea
+
+This plant developed a severe spider-mite infestation. It died slowly despite heroic interventions. The ficus audrey will move into its pot.
+
+{{< image 
+    src="images/pinstripe-calathea-dying.jpg"
+    caption="Pinstripe calathea dying, RIP. goodbye" >}}
+
+## Money tree
+
+This plant came potted in a small plastic pot. It needs to match or the whole thing is SHOT and the aesthetics are TRASH. Upgrade.
+
+{{< image 
+    src="images/money-plant-repot-complete.JPG"
+    caption="money plant (and old plastic orchid pots)" >}}
+
+## Orchids
+
+These orchids were gifted to us and came packaged in very wet soggy media, which is fine for transporting the orchids long distances to keep them alive, but will rot the roots with time. Some roots were rotted already and had to be pruned. We repotted in orchid bark which had to be soaked first. Also, we upgraded their pot from plastic to a clay pot with vents.
+
+
+{{< image 
+    src="images/orchid-bark-soak.JPG"
+    caption="Soaking orchid bark" >}}
+    
+{{< image 
+    src="images/orchid-root-pruning.JPG"
+    caption="prune rotted roots" >}}
+
+{{< image 
+    src="images/orchids-repot-complete.JPG"
+    caption="orchids in new pots" >}}
+

container/site/content/posts/2026-07-07-home-ops/index.md

@@ -0,0 +1,135 @@
++++
+categories = ["build","software"]
+date = 2026-07-07T10:00:00-05:00
+description = ""
+draft = false
+slug = "2026-07-07-home-ops"
+title = "🏗️ Home Ops Upgrades"
+author = "nicholas"
++++
+
+As the number of self-hosted services I use regularly has grown, managing them by hand began to feel wrong, and occasionally annoying and tedious. It ends now!
+
+{{< image 
+    src="images/portainer-container-dashboard.png"
+    caption="Container dashboard - many apps" >}}
+
+In the beginning, my workflow was pretty sloppy since much of the deployment/management depended on me remembering to restart a container or update a version, manually copy a secret here and there. Things like this. Totally maintainable, sustainable with some effort, but it is not *the way*. And to some degree these manual interventions will always be necessary, but it will serve me well to reduce them and automate them away as much as reasonable to help these apps live far into the future with little fuss. Many of these apps have proven their usefulness to me over many years, so I have begun to take their management more seriously, slowly taking steps toward git-ops patterns and best practices. Before: scattered `.env` files. Flat directory of compose files. No documentation. Manually copying secrets by hand. Manually rebuilding host dependencies by hand. Now: a single command issued by a single click of a button (maybe I am overstating the simplicity here...nevertheless) will handle mostly everything I care about. Host setup, Compose projects, rendered secrets, state directories, validation, and deployment are all described in one place. Easy!
+
+## Git Repo as Source of Truth
+
+I am trying to move my app hosting toward git-ops patterns, where the git repo is the "source of truth" which describes the desired state of my home apps/services etc. The repo checkout itself should stay disposable. This will be useful to me because changes become reviewable and repeatable. If I move a service to a different host, for example, or a port changes, or a secret is added, or a stack is disabled, that change will be obvious in git logs, and it will be easily deployable since everything is in one place.
+
+Prior to this overhaul, I had one repo for each host. I decided to combine all host config to a single repo for simplicity, since managing the deployment logic across two and possibly many more repos would sort of defeat the original purpose of making things simpler and more robust. Configuration would drift apart, and all of my annoyances under the previous 'workflow' would return. 
+
+## Ansible
+
+The main tool making the magic happen is Ansible. This is sort of the 'infrastructure-as-code' layer, configuring the OS host environment in all the ways necessary to run the apps. It installs packages, configures Docker, creates state directories, manages the deploy user, mounts storage, renders secrets, and starts containers, stopping short of actually provisioning the VM/host itself (Maybe coming soon).
+
+{{< image 
+    src="images/actions-deploy.png"
+    caption="Gitea Actions deploy workflow" >}}
+
+
+### Inventory
+
+I used Ansible inventory to map and name the hosts, set the connection details, and group machines so the same playbooks behave differently for each host. In the new `home-ops` repo, inventory lives in `ansible/inventories/production/`. Shared defaults live in `group_vars/all.yml`, host-specific settings live in, for example `group_vars/edge.yml`,`group_vars/server.yml`. This is how Ansible can decide which Compose projects run on the `edge` host and which run on the `server` host.
+
+### Roles
+
+I am using roles to keep the playbooks organized. There is some reuse between each playbook since the host env is basically the same. The playbook will define the order of operations, while the roles will be the steps of host setup:
+
+- related work stays together
+- shared setup can be reused across host groups
+- `edge`-only and `server`-only behavior stay separated
+- common tasks do not need to be copied between playbooks
+
+In this repo:
+- `common` prepares the basic host environment
+- `docker` installs Docker and Compose
+- `state` creates runtime state directories
+- `storage-mounts` manages NAS mounts
+- `edge-host` handles edge-specific host setup
+- `step-ca` syncs private CA trust
+- `preflight` checks required rendered files
+- `compose-projects` runs the enabled Compose apps
+
+### Compose Projects
+
+Each app "stack" is a Compose project under `stacks/apps/` and `stacks/edge/`. A stack can include more than one container, since many apps depend on supporting services/containers, e.g. web container, a database, a cache, a worker.
+
+### State Directories
+
+Ansible creates `state_root` and app-specific state directories. Compose uses `${STATE_ROOT:-/opt/home-ops-state}`.
+
+State lives outside the repo because as I mention above, the repo checkout should stay disposable. A deploy can replace or update `/opt/home-ops` without deleting databases, uploads, generated config, caches, or other runtime data. The repo describes the desired configuration; `/opt/home-ops-state` holds the mutable state created by running services.
+
+### Deployment Paths
+
+Production deployments can run from Gitea Actions or manually from a control machine. A control machine is a machine running Ansible which connects to the target hosts over SSH and applies the playbooks there. Manual Ansible runs are useful for development, testing, and recovery when the Gitea workflow is unavailable. For example, from a prepared control machine:
+
+```sh
+ansible-playbook playbooks/server.yml
+```
+
+But the simplest/easiest way to deploy is to click a button in a web UI. My `Deploy` workflow supports `all`, `edge`, and `server` targets.
+
+
+{{< image 
+    src="images/deploy-workflow.png"
+    caption="Deploy workflow in Gitea" >}}
+
+### Data
+
+Large data which ought to live on my NAS are bind-mounted under `/mnt/data` and `/mnt/backup`. Ansible can create mount point directories, but NAS ownership and ACLs are managed on the NAS side. The point is to keep large media and backup data out of the repo host filesystems. They take up a lot of space and do not belong on the fast, limited storage on container hosts.
+
+Some services use Docker volumes for persistent state, for convenience, since I am happy to let Docker manage the data and do not much care about these details. For long-lived or state that I care about, I want to use `/opt/home-ops-state` which is easier to reason about because it has an explicit path and can neatly be included in a backup/restore operation.
+
+### Secrets
+
+Secrets are stored in SOPS and rendered before Compose starts. Plaintext `.env` files, private keys, and decrypted secrets are not committed to the repo. Keeping encrypted secrets in the repo is useful because the secret manifest can live next to the configuration that needs it. I can see that a service requires a `.env` file or mounted secret file without committing the plaintext values. Secret changes also get version history like any other infra change and the actual secret values remain encrypted. This is much preferred to keeping secrets as random files on one host and manually copying them onto others. The repo can describe which secret files must exist, where they should be rendered, and which services consume them. SOPS handles the encryption and Ansible handles rendering the files during deploy.
+
+#### App Env Secrets
+
+Most app secrets are rendered from the same SOPS `secret_files` list. Ansible decrypts the SOPS file on the control machine, then writes each secret file to its destination before Compose starts. The app secrets mentioned are mostly in the form of a per-service `.env` files that live next to the app's `compose.yaml`. Compose reads that file and uses the values for environment variables. A couple of other apps use the same idea, but instead require app-specific secret files rather than `.env` files. These are still SOPS-rendered secrets, but the destination is a mounted runtime file rather than a `.env` file.
+
+#### Deploy Secrets
+
+Deploy secrets are not consumed by the apps themselves but instead are used by the deployment system so Gitea Actions or a control machine can connect to the hosts and render production secrets.
+
+For example, the Gitea deploy workflow uses secrets:
+- `DEPLOY_SSH_KEY`: allows the action runner to SSH to the inventory hosts as the `deploy` user
+- `SOPS_AGE_KEY`: decrypts `secrets/sops/production.sops.yml`
+
+
+{{< image 
+    src="images/actions-secrets.png"
+    caption="Gitea Actions secrets" >}}
+
+
+This separation is useful because deploy credentials have a different lifecycle from app credentials. Rotating a deploy key should not require changing app `.env` files, and changing an app password should not affect the deployment path.
+
+### Deploy User
+
+The `deploy` user is used for production Ansible runs and gets passwordless sudo through a dedicated sudoers file. This gives the ansible automations its own dedicated identity instead of using my personal login. There is a playbook for creating the user, installing the committed public key, and granting passwordless sudo.
+
+
+## Renovate
+
+Renovate watches my Docker images and opens PRs when updates are available, but only if I select the proposed update in the Dependency Dashboard. This dashboard is a Gitea Issue the `renovate-bot` user creates and manages, and it is used by Renovate to decide which images should be updated by way of a pull request. Since I do not want every Docker image involved yet I limit Renovate to only the Compose stacks in my whitelist.
+
+{{< image 
+    src="images/renovate.png"
+    caption="Renovate dependency dashboard" >}}
+
+The Renovate workflow can run on a schedule or manually from Gitea Actions. Renovate proposes updates which I can review and deploy manually (or automatically if I want, I suppose). It is highly configurable, but I have kept my own configuration simple and mostly manual for now.
+
+This workflow requires some secrets:
+- `RENOVATE_TOKEN` Gitea access token so Renovate can create issues and PRs. 
+- `RENOVATE_GITHUB_COM_TOKEN` used by Renovate to access GitHub-hosted release notes and metadata. 
+
+## Future Changes
+
+Future changes will mostly be about making hidden state less hidden, which means moving important Docker volumes into explicit state paths. I may also revisit secrets management approach later if I want to experiment with using a secret manager e.g. HashiCorp Vault. It is still possible to go a layer deeper than the apps, into the true infrastructure layer with Terraform or OpenTofu. Lots of possibilities, but for now, it is good enough.
+
+✅ Done.

container/site/hugo.toml

@@ -116,7 +116,7 @@ ignoreErrors = ["error-remote-getjson", "error-missing-instagram-accesstoken"]
     #  whether to show the author
     author = true
     # Site creation time
-    since = 2024
+    since = 2021
     # ICP info only in China (HTML format is supported)
     icp = ""
     # license info (HTML format is supported)