Forem: Amit Singh

Source Score: Using AI to automate addition of new sources

Amit Singh — Mon, 11 May 2026 11:14:19 +0000

This post is a continuation of a microservice I've been building. You can check out my last post in the series here.

Automate News Source Ingestion with Firecrawl, OpenRouter, and GitHub Actions

TL;DR : I turned a manual, copy‑paste routine for adding news outlets into a fully automated, monthly GitHub Actions workflow. The pipeline scrapes a ranking page with Firecrawl, extracts clean URLs using three free‑tier LLMs on OpenRouter, generates Source YAML files, and opens a PR that lands these sources straight on the live dashboard post merge.

How it all began

When I first ingested sources in source‑score database I seeded it with five manually‑added outlets. It was enough to verify that the endpoints work, but I kept thinking about the “real” world: the top global media brands that people actually read. I wanted the repo to stay fresh without someone constantly creating PRs to add new sources.

The idea was simple on paper: fetch the latest list of popular English‑language news sites, turn each entry into a valid Source document, and let the existing CI validate and ingest them. In practice though, I ran into three big hurdles (which further break down into their own little challenges as you'll see):

Finding a reliable source – I discovered a page on PressGazette website that publishes the top 50 news sites each month, but the raw HTML was going to be a mess.
Extracting just the URLs – The page’s markup mixed headlines, ads, and footnotes. A regular regex wouldn't have been enough.
Keeping the process cheap – I didn’t want to spin up a paid scraper or a paid LLM every month.

The first breakthrough: Firecrawl does the heavy lifting

Firecrawl’s Python SDK made the scraping step painless and their free tier limits are high enough for my requirements. A tiny wrapper takes a URL and returns a clean Markdown:

def main():
    if len(sys.argv) < 2:
        print("Usage: scrape_firecrawl.py URL", file=sys.stderr)
        sys.exit(1)

    url = sys.argv[1]
    api_key = os.getenv("FIRECRAWL_API_KEY")

    fc = Firecrawl(api_key=api_key)
    try:
        doc = fc.scrape(url, formats=["markdown"])
    except Exception as e:
        sys.exit(f"Error scraping {url}: {e}")

    print(doc.markdown)

Running it against the ranking page gives me a tidy Markdown blob that still contains a lot of noise, but it’s a far better starting point than raw HTML. I want to store the scraped content in plaintext and forward it to LLMs as it is. For this requirements, the markdown format seemed the best of all the available options.

Using LLMs to extract news source URLs from the scraped data

Before diving into the technical details, I'd like to add that so far my AI usage was limited to: Claude CLI for high level project management, Copilot VSCode extension for code generation, and various chat services (ChatGPT, Gemini, Kimi, etc) for any questions or learning new stuff. None of them, however, were going to meet my new requirements. This, and the fact that I love free stuff, led me to OpenRouter, and I'm so glad I signed up. Shout out to them for their generous free tier limits and giving people like me the option to use these new, super capable models for free.

Coming back to the main problem, the next step is where OpenRouter shines. I wrote a small helper script that:

Loads a Markdown‑processing skill, that I wrote (using the power of googling) to help the model process MD files, from my repo. I have some other skills there as well that I've been experimenting with to help me write these blogs, maybe I'll cover them later 😉
Sends the scraped Markdown file content to three free models (gemma‑4‑31b‑it, nemotron‑3‑nano‑omni‑30b, gemma‑4‑26b) until one returns a non‑empty answer. Sometimes requests to OpenRouter API fail because the model doesn't respond. To deal with that I'm iterating over these 3 models and so far at least one of them has always worked.
Asks the model to list the top‑10 latest most popular news outlets and output only URLs, one per line.

SOURCE_QUESTION = "What are the top 10 latest most popular news outlets in the world listed in this document? Only output URLs of these news outlets separated by new lines. Do not output anything else."
def process_raw_doc(md_processing_skill: str, md_doc: str, api_key: str) -> str:
    for model in FREE_MODELS_DOC:
        payload = {
            "model": model,
            "messages": [
                {"role": "system", "content": md_processing_skill},
                {"role": "user",
                 "content": f"Here is a web page in Markdown:\n\n{md_doc}\n\n"
                            f"Answer this question:\n{SOURCE_QUESTION}"}
            ],
        }
        raw_source_list = req_openrouter(payload, api_key)
        if raw_source_list:
            break
    if not raw_source_list:
        sys.exit("Error: All models failed.")
    return raw_source_list

The model’s answer still contains stray characters and occasional combined or shortened URLs.

To get a clean list of URLs, I'm running a second OpenRouter call that uses the built‑in web‑search tool to validate each line and verify the URL is correct. Following is the payload for my second OpenRouter request:

content = (f"Here is a raw list of URLs of news outlets with each line containing one or more unformatted URLs:\n\n"
    f"{raw_source_list}\n\n"
    f"Use web search to access these URLs and discard those that are invalid. Do not scrape the web page, only check if the URL is valid\n"
    "Based on successful web searches, return a list of corresponding properly formatted URLs without any extra test. Keep only one URL per line."
)
payload = {
    "model": model,
    "messages": [
        {
            "role": "user",
            "content": content
        },
    ],
    "tools": [
        {"type": "openrouter:web_search"}
    ]
}

From source URLs to proper `Source` YAML

With a verified list of URLs in hand, the next step is to generate a full Source document for each outlet. To achieve that goal, yeah you guessed it right, another OpenRouter API call.
I'm adding an ingested source yaml doc as a schema example, then asking the model to fill in the blanks by using the web search tool again:

content = (f"Extract schema from the following yaml document and store it as source_schema:\n\n"
    f"{sample}\n\n"
    f"Following is a list of urls of media outlets separated by new lines\n\n"
    f"{sources}\n\n"
    "Use web search to fetch information about these media outlets and create yaml docs for each of them following the source_schema schema. Do not output anything except for the yaml documents for these medial outlets separated by ---."
)

payload = {
    "model": model,
    "messages": [
        {
            "role": "user",
            "content": content
        },
    ],
    "tools": [
        {"type": "openrouter:web_search"}
    ]
}

The response is a string of YAML manifests separated by ---. I split, filter, and deduplicate against existing files to avoid overwriting anything.

Writing the new files (safely)

The deduplication logic avoids creating ingestion docs for sources that already exist in the repository. It loads every YAML under sources/, compares name and uri, and returns only truly new entries. The final loop writes each doc to a sanitized filename:

for doc_str in unique_src_docs:
    parsed = yaml.safe_load(doc_str)
    filename = parsed.get('name')
    if not filename:
        continue
    filename = re.sub(r"[^A-Za-z0-9._-]+", "-", filename.strip()) + ".yaml"
    path = os.path.join(sources_dir, filename)
    if os.path.exists(path):
        continue
    with open(path, 'w', encoding='utf-8') as f:
        f.write(doc_str.strip() + "\n")

All files land in sources/ ready for the existing validation workflow.

The actual automation: GitHub Actions workflow

Now that we have all the scripts ready, time for the final piece of the puzzle, the scheduled CI job.

It runs on the first day of each month
checks out the repo
creates a new branch
sets up Python
runs a tiny wrapper shell script that strings the three Python helpers together
commits any new YAML files
and opens a PR:

When the PR lands, the existing validate.yml workflow validates the new YAML files, and the post_on_merge.yml workflow posts them to the API when the new source docs get merged, now ready to be fetched by the live dashboard.

The results so far

Source fetch workflow: https://github.com/SatyaLens/sources/actions/runs/25617971999/job/75199251257
Automated PR: https://github.com/SatyaLens/sources/pull/22
Ingestion run: https://github.com/SatyaLens/sources/actions/runs/25628583734/job/75228007512
Live dashboard: https://satyalens.github.io/source-score-dashboard/

All the new sources appear with correct URLs and short descriptions, and the CI passes without a hitch. The whole process now takes less than a minute of human time each month, and that too just to merge the PR 😁

What’s next?

Adding sources was the low‑hanging fruit (relatively). The next challenge is to replicate the same pattern for claims and proofs. A larger data set, more complex validation, and a higher chance of model hallucination.

Completing this goal led me to discovering OpenRouter and learning how to use AI agent skills, can't wait to see what the next challenge brings.

Conclusion

By chaining Firecrawl, OpenRouter, and GitHub Actions I turned a tedious, error‑prone task into a reliable, monthly automation. The result is instantly visible on the live dashboard, and the repo stays in sync with the world’s most popular news outlets.
If you try this yourself and have a suggestion or question, feel free to open an issue or drop a comment.

Continuing the Microservice Journey...

Amit Singh — Tue, 05 May 2026 14:58:19 +0000

This post is a continuation of the microservice I've been building. You can check out my last post in this series here.

Over the years, I've come across headlines that turned out to be half‑truths or outright hoaxes. Around the same time, I’ve also been spending a lot of time practicing microservice development in Golang, so I started wondering: why not build something that combines both interests? 🤷
That idea became source-score, a project that aims to rate news sources based on how often the claims they publish turn out to be true. It’s still very early and nowhere near finished 🫣, but I have a demo instance up and running. In this post, I’ll briefly walk through what the project is meant to do, how it currently works under the hood, and where I want to take it next.

TL;DR

Three repos work together to turn YAML documents into a live dashboard:

Repo	What it does	Key tech
sources	Stores and validates YAML docs (sources, claims, proofs)	Python, YAML, GitHub Actions
source‑score	Go microservice that verifies claims and calculates scores	Go, Gin, REST, Swagger
source‑score‑dashboard	Static UI that polls the API and shows sources, claims, proofs	HTML, CSS, vanilla JS

The demo instance is live at https://satyalens.github.io/source-score-dashboard/.

I've manually added 5 news sources, 2 claims for each of them with 1 proof backing up each claim.
The app is deployed on Render free instance so it might take a few seconds for it to come online and return data 🙏

The Idea

The model is intentionally simple for now.

A source is a media outlet or information provider. A claim is something that source has published. A proof is another link that either supports or refutes that claim.

Once claims have proofs attached, the API can verify them. Right now, the verification logic is basic: if a claim has more supporting proofs than refuting proofs, it is marked valid. A source score is then calculated like this:

valid checked claims / total checked claims

So if a source has two checked claims, and both are valid, the score is 1.

This is not supposed to be the final credibility algorithm. I wanted the first version to be understandable, testable, and easy to argue with. A simple score gives me something concrete to improve instead of starting with a scoring model that looks impressive but is hard to explain.

The Architecture

The project is split into three parts because I wanted the data, backend, and dashboard to stay separate.

sources: The Data Pipeline

The sources repo stores structured documents under three folders:

sources/
claims/
proofs/

Each document is written in YAML and validated against an OpenAPI schema. A source document describes the outlet. A claim document points back to a source using the source URI digest. A proof document points back to a claim and records whether the proof supports the claim.

This repo also has a small CI flow:

validate new YAML documents on pull requests
post newly added documents to the API after merge
refresh claim verification and source scores on demand or after the document post workflow is completed successfully

I like this setup because it makes the dataset reviewable. Instead of manually sending API requests every time I want to add a source or proof, I can add a structured file, validate it, and let GitHub Actions handle the posting step. This repo also acts as a user friendly interface for someone who is not super technical to add documents.

source-score: The API

The source-score repo is the backend service.

It is a Go API built with Gin, GORM, PostgreSQL, and OpenAPI-generated types. It exposes endpoints for creating and reading sources, claims, and proofs. It also has endpoints to verify claims and calculate source scores.

The main flow looks like this:

source -> claim -> proof -> claim validation -> source score calculation

There are a few technical choices in the first version that I wanted to keep simple:

HTTPS URIs identify sources, claims, and proofs.
SHA-256 URI digests are used as stable IDs.
OpenAPI defines the request shapes (I thank my past self for this choice because now I can use the OpenAPI schema to validate documents before ingesting them).
The API can be protected with an X-API-Key header.
The dashboard is allowed through CORS for the live demo.
Unit and acceptance tests cover the main source, claim, and proof flows.

The scoring logic is intentionally small right now. Checked claims are grouped by source, valid claims are counted, and the source score is updated as a ratio.
You can access the demo instance Swagger UI, deployed on Render here. Shout out to Render for helping people like me test their side projects with their free tier.

source-score-dashboard: The Demo UI

The source-score-dashboard repo is a small static dashboard.

No framework. Just HTML, CSS, and JavaScript. The code is mostly AI generated. I'm frontend-ally disabled so please cut me some slack here 🥲

It has three pages:

index.html   -> sources
claims.html  -> claims for one source
proofs.html  -> proofs for one claim

The dashboard calls the live API and refreshes every few seconds. Clicking a source opens its claims. Clicking a claim opens the proofs attached to it.

It is plain on purpose. I wanted a working view of the data before spending time on UI polish.

How the Score is Computed

// pkg/domain/source/source_service.go
func (s *Service) RecalculateScore(ctx context.Context, sourceID string) error {
    claims, err := s.repo.ListClaimsForSource(ctx, sourceID)
    if err != nil { return err }

    var valid, total int
    for _, c := range claims {
        if !c.Checked { continue } // skip unverified claims
        total++
        if c.Validity { valid++ }
    }
    score := float64(valid) / float64(total)
    return s.repo.UpdateSourceScore(ctx, sourceID, score)
}

Why this matters: The score is a simple ratio, but it gives a quick sanity check. A source with a score of 0.9 has 9 valid claims for every 10 verified claims – a strong signal that the outlet is generally reliable.

What I want to improve next

The next step is to keep adding more sources, claims, and proofs.

After that, the scoring model needs to get smarter. A simple ratio is fine as a prototype, but it does not capture enough nuance. Some claims matter more than others. Some proofs are stronger than others. Some claims are too ambiguous and hard to prove right or wrong conclusively. Sources publish across different topics, and I probably should not treat a sports claim and a geopolitical claim as if they carry the same weight.

Some improvements I want to work on:

better scoring rules
topic-wise source scores
richer proof metadata
easier contribution flow for new YAML documents
dashboard filtering and sorting
clearer handling for conflicting proofs
some score associated with unverified claims

For now, Source Score is a personal side project born out of a very practical annoyance: I want a better way to know which news sources I should trust.

Maybe, over time, it can help others wondering the same thing.

Sharing music with Navidrome, Filebrowser and Civo

Amit Singh — Thu, 05 Mar 2026 13:24:36 +0000

This post builds on top of my last one where I deployed Navidrome on a K3S cluster with Longhorn volumes mounted to store data and music files.

Before we get started, all my code is stored in the following repo.

semmet95 / navidrome-deployer

A simple chart to deploy Navidrome on a Kubernetes cluster

Navidrome Deployer

Prerequisites

Before deploying navidrome-deployer, ensure the following tools are installed:

kubectl - Kubernetes command-line tool
go - Go programming language
mage - Go-based task runner
helm - Kubernetes package manager
helmfile - Helm values file manager

Installation on a cluster

To install the latest release

helmfile apply -f https://github.com/semmet95/navidrome-deployer/releases/latest/download/helmfile.yaml

To install a specific version

helmfile apply -f https://github.com/semmet95/navidrome-deployer/releases/download/<version>/helmfile.yaml

Local Setup and Deployment

To deploy navidrome-deployer locally, execute the following command:

./scripts/local-deployment.sh

View on GitHub

In this post I'll share how I deployed Navidrome on a Civo cluster and exposed interfaces to upload and play music.
The last release I made of navidrome-deployer deployed Navidrome on a K3S cluster and exposed Navidrome UI to play music. However, I was still using kubectl commands to copy music files into Navidrome pods. This will be our starting point.
To begin with, we need some way to mount the volume that stores these music files and provide a UI that lets users upload and manage them. This search led me to Filebrowser.

I must say, integrating Filebrowser was a lot easier than I expected. All I had to do was create a Deployment to run the filebrowser/filebrowser:v2.61.0 image and mount the music-volume PVC that was already being used by Navidrome deployment. Filebrowser lets you manage files under the /srv path, mount that music volume on this path and voilà, you now have a UI to upload music to Navidrome.

I did have to make some config changes though. By default, Filebrowser pod logs the admin user password that you can use to log in and access admin-level settings, but letting everyone log in as the admin is probably not a good idea. Luckily, Filebrowser has an option to let users sign up.

Now I could deploy Filebrowser, log in as the admin, change the password, and enable user sign up. But there's a way to slightly decrease the manual setup by using the filebrowser cli. When I run the following command:

filebrowser config set -s --createUserDir

Filebrowser lets users create new accounts and generates their home directory automatically. This comes with a catch, but we'll dive into that when we get to the code changes section.

Creating public endpoints

Now that I had interfaces to play and upload music, ready to be exposed, I needed to figure out a way to expose them safely. This was a problem because networking is not my strongest suit. Thankfully Civo has a tutorial that tackles this exact problem.

Using Traefik LoadBalancer

When creating a Civo cluster, you can select the Traefik v2 (LoadBalancer) addon, and it will provision a load balancer that will handle all the public traffic. The part that surprised me, pleasantly, was how easy it was to get a self-signed certificate. Just combine cert-manager and Let's Encrypt to issue a Certificate and then use it in Traefik's Ingressroute for incoming HTTPS traffic. I also learned about some "best practices" type middlewares that you can add to the Ingressroute to make it more secure, we'll go over them down the line (as you scroll).

Alright, before we jump into the code, time to see Filebrowser and Navidrome in action.
This is the Filebrowser endpoint which is the uploader interface. In my head, it's like the interface artists could interact with to upload their music (not that it's even remotely close, but I like the idea). You can create a new account, log in and start uploading .mp3 files. It might take a few seconds, but the song will appear on Navidrome UI, ready for you to play and enjoy.
This is the Navidrome interface where you can play the uploaded music. I was hoping to create an "open Spotify web" type experience where you can play music without having to create an account but since I couldn't achieve that, I created a guest account with the following credentials.

username: guest
password: guest

Log in using the guest account, and you can play music uploaded by all the users through the Filebrowser interface.
P.S.: Don't worry, I have configured Navidrome so this password cannot be changed.

Putting it all together, this is what it looks like.

Into the code

And now, we finally dive into the code changes. There's a lot to cover, so I'll group them into sections.

Integrating Filebrowser

When you use Filebrowser UI to upload files, all of them are stored in the /srv directory (or subdirectories under it). This is where our music files will be uploaded, meaning this where Navidrome needs to fetch music from. Navidrome deployment already uses a Longhorn volume to store music files. If we set the access mode of this volume's PVC, music-volume, to ReadWriteMany and mount it in the Filebrowser deployment on the /srv path, we are good to go. All the music files will be shared by both the deployments, Filebrowser manages them, Navidrome plays them.
Now that we have figured out what Filebrowser's integration point is going to be, time to configure it based on our requirements. We need to run the following commands to allow user signups, create user directories, and lock the admin account password.

filebrowser config set -s --createUserDir
filebrowser users update admin --lockPassword

Now here comes the tricky part, you cannot configure Filebrowser database while it's being used, which is not surprising but on top of that, you need to run these commands only after Filebrowser has booted up once and created the admin account and the database. It was at this moment I remembered how useful Helm hooks are.
So following is the strategy I ended up with:

Store Filebrowser database in a Longhorn volume and mount it in the Filebrowser deployment.
Create a job, filebrowser-reconfig, with post-install,post-upgrade helm hooks that also mounts this volume. This way the job will only run after the Filebrowser deployment is ready, and the database is created.
Run the following commands in the job container to safely update Filebrowser database.

DEPLOYMENT="filebrowser"
# ensure filebrowser deployment is ready
kubectl wait --for=condition=Available deployment/$DEPLOYMENT -n $NAMESPACE --timeout=300s

# store the original replica count
ORIGINAL_REPLICAS=$(kubectl get deployment $DEPLOYMENT -n $NAMESPACE -o jsonpath='{.spec.replicas}')

# scale the deployment down to 0 replicas
kubectl scale deployment $DEPLOYMENT -n $NAMESPACE --replicas=0
kubectl wait --for=delete pod -l app=filebrowser -n $NAMESPACE --timeout=120s

# run the filebrowser cli commands
cd database
filebrowser config set -s --createUserDir
filebrowser users update admin --lockPassword

# scale the deployment back up to the original replica count
kubectl scale deployment $DEPLOYMENT -n $NAMESPACE --replicas=$ORIGINAL_REPLICAS

One last thing, this job runs filebrowser and kubectl CLI commands, so I had to create an image that contains them both. Here is the Dockerfile and the image is built and published every time a new release is created.

There was one more issue I kept running into. Filebrowser pods would often crash with issues related to accessing the database, so as a quick fix I add an init-container to run the following command.

chmod -R 777 /database

And I'm running this init-container and the filebrowser container as root. It's far from ideal but it did fix the issue.

Exposing Filebrowser and Navidrome deployments to public traffic

Earlier I mentioned I was following a Civo tutorial to issue certificates using Let's Encrypt which in turn were supposed to be used by Ingress. However, I wanted to add some security to the public endpoints. After doing a little research I found that if I use Traefik's IngressRoute, I could add Middleware layers to the routes that harden the endpoints against common browser-based attacks. To be specific, I added rate limiting and HSTS enforcement. I doubt that's enough but I think it's a good starting point.

Coming to the IngressRoute itself, I have created 2 routes, one for the Filebrowser deployment and the other for Navidrome. Here I ran into a little challenge. The host name for each route is dynamic because the base domain includes Traefik LoadBalancer ID. Luckily, this ID is stored as an annotation added to the traefik service in kube-system namespace. I'm using the lookup function in _helpers.tpl to fetch this service and in turn, the loadbalancer ID from the annotations.

{{- define "baseDomain" -}}
{{- $svc := (lookup "v1" "Service" "kube-system" "traefik") -}}
{{- $annotations := $svc.metadata.annotations -}}
{{- $loadbalancerId := index $annotations "kubernetes.civo.com/loadbalancer-id" -}}
{{- printf "%s.lb.civo.com" $loadbalancerId -}}
{{- end -}}

Then I'm referring to the baseDomain in my Ingressroute. I also found out that you can specify path patterns in the routes to accept, deny, or redirect traffic. I'm currently using it to deny requests targeting API endpoints and admin level settings. So everything combined, this is how the routes are defined.

routes:
  - match: Host(`navidrome.{{ include "baseDomain" . }}`) && ! PathPrefix(`/api/user`)
  - match: Host(`navidrome-uploader.{{ include "baseDomain" . }}`) && ! PathPrefix(`/api/settings`) && ! PathPrefix(`/settings/global`) && ! PathPrefix(`/settings/users`)

Minor test updates

To ensure I have basic smoke tests to cover these changes, I have updated them to verify cert-manager deployments are healthy and that the Filebrowser DB configuration job is completed successfully.
In my last article I mentioned that I was disabling firewall service to create a K3S cluster and install Navidrome Deployer chart locally. This was not ideal and after reading K3S docs I found out that I could just add some exceptions to the firewalld service to whitelist K3S cluster and allow inter-pod communication by running the following commands in my test setup script.

firewall-cmd --permanent --add-port=6443/tcp
firewall-cmd --permanent --zone=trusted --add-source=10.42.0.0/16
firewall-cmd --permanent --zone=trusted --add-source=10.43.0.0/16
firewall-cmd --reload

Having covered everything, this is the final version of my helmfile.

helmDefaults:
  timeout: 600
  wait: true
  waitForJobs: true

repositories:
- name: longhorn
  url: https://charts.longhorn.io
- name: cert-manager
  url: quay.io/jetstack/charts
  oci: true
- name: navidrome
  url: ghcr.io/semmet95/navidrome-deployer/charts
  oci: true

releases:
- name: cert-manager
  namespace: cert-manager
  chart: cert-manager/cert-manager
  version: v1.19.4
  createNamespace: true
  values:
  - crds:
      enabled: true
  - cainjector:
      resources:
        requests:
          cpu: 50m
        limits:
          memory: 256Mi
- name: longhorn
  namespace: longhorn-system
  chart: longhorn/longhorn
  version: 1.11.0
  createNamespace: true
  values:
  - longhornUI:
      replicas: 0
- name: navidrome
  namespace: navidrome-system
  chart: navidrome/navidrome-deployer
  version: 0.21.2
  createNamespace: true
  disableValidationOnInstall: true
  needs:
  - cert-manager/cert-manager
  - longhorn-system/longhorn

If you have a cluster with Traefik installed, you can install Navidrome Deployer with this one-liner.

helmfile apply -f https://github.com/semmet95/navidrome-deployer/releases/download/v0.21.2/helmfile.yaml

Even though it's just meant to be a demo instance, I know there's a lot of room for improvement, so that's what I would end this article with.

Currently accessing Navidrome requires sharing credentials. I need to find a way to either let users access the music without requiring an account, or to automate that process behind the scenes in a way that scales up well.
Filebrowser and Navidrome containers are running as root. They are sharing a PVC so I need to switch to a non-root user without having them interfere with each other's access to the shared files.
I have also observed significant delay (up to 30 seconds) on Navidrome's side before it imports newly uploaded music. Some discussions around this issue suggest that it could be because of auto generated directories like lost+found that Navidrome watcher might not have access to, leading to it crashing. I've added a postStart hook to Navidrome and Filebrowser containers to delete this directory but that doesn't seem to have any effect.
I would also like to add some restrictions to Filebrowser so users may only upload MP3/audio files.

Hopefully the next time I write about this project all of these would be resolved. If you, the reader, have any suggestions for me feel free to drop them in the comment section. Until next time 🫡