bouncer
← Back

Heavy Metal Cloud · 1.1K views · 40 likes

Analysis Summary

20% Minimal Influence
mildmoderatesevere

“Be aware that while the software tutorial is educational, the hardware links in the description are affiliate-based, meaning the creator has a financial incentive to recommend the specific components used in the setup.”

Ask yourself: “Did I notice what this video wanted from me, and did I decide freely to say yes?”

Transparency Transparent
Human Detected
95%

Signals

The transcript exhibits clear signs of a human creator, including personal anecdotes about their specific homelab journey and natural, unscripted speech fillers. The content is part of a cohesive, manually produced series with deep technical integration that lacks the generic, formulaic structure of AI-generated tech tutorials.

Natural Speech Patterns Use of personal possessives ('my little cloud', 'my last video'), contractions, and conversational transitions ('Okay, from this point on', 'All right, there's one more section').
Contextual Continuity References specific previous videos in a series ('In my last video about shared services', 'check out my videos explaining TLS') and specific hardware setups.
Technical Specificity Detailed explanation of local infrastructure (Proxmox, Longhorn, Kubernetes) with a clear, non-formulaic pedagogical style.
Channel Identity Niche technical content with custom GitHub repositories and affiliate links for specific 'Cloud Hardware' used in the video.

Worth Noting

Positive elements

  • This video provides a clear, high-quality technical walkthrough of Helm charts, Kubernetes secrets, and persistent storage configuration for a specific DevOps tool.

Be Aware

Cautionary elements

  • The integration of affiliate hardware links means the 'Cloud Hardware' recommendations are commercially motivated rather than purely objective technical choices.

Influence Dimensions

How are these scored?
About this analysis

Knowing about these techniques makes them visible, not powerless. The ones that work best on you are the ones that match beliefs you already hold.

This analysis is a tool for your own thinking — what you do with it is up to you.

Analyzed March 13, 2026 at 16:07 UTC Model google/gemini-3-flash-preview-20251217
Transcript

Okay, my little cloud is starting to come together. I have one server that's dedicated to DNS and some other networking task. In my last video, I set up a server for shared services that'll be used by my Praxmax cluster. Today, I'm going to create my first shared service called a container registry. So, what's the purpose of a container registry and why do I need it in my little cloud? You see all my applications will be running on top of Kubernetes which sits on top of Proxmox. Let's zoom into Kubernetes and take a closer look. Applications in Kubernetes run in something called a pod. The pod contains your application code which runs inside containers like Docker. What the pod gives us is a life cycle for creating the containers and tearing them down. During the creation process, the pod will grab the container image and that image has to come from somewhere and that somewhere is called a container registry. A container registry is a repository that catalogs and stores container images. Some popular registries are DockerHub and Red Hats Quay.io, but for my cloud, I'll create my own so I can keep everything in house. The software I decided to use for my container registry is called Twony. I'll have a link to the GitHub page in the description below. Before the install, there are a few things I'll need. First is a way to authenticate to the service. And for that, I'll use a simple username and password. Those credentials will be encoded using a tool from the HTTP Apache project. Again, the Twi service will be installed on my shared services cluster on top of Kubernetes. I'll use a tool called Helm to handle that. Finally, I'll be securing the service using a TLS connection. If you want to learn more about how I created the certificates, check out my videos explaining TLS. Okay, from this point on, I'll be typing in some commands into a shell. To make things easier, I've created a GitHub page with all the steps. Link in the description below. I'll also assume that you have a Kubernetes cluster running and it's ready to go. To authenticate to our registry, we'll need an encoded username and password. I'll first need to install some tools from Apache and then run this command to perform the encoding. And this is what the encoding will look like. With that in place, I need to create a Kubernetes secret for my TLS certificate and private key. I'll use these cube cuddle commands to create the name space and the secret. The important part here are these two files, the certificate containing the public key and the private key. Make sure the files are located in the same directory where you're running the command. Here's another command to inspect the secret that we just created. With the dependencies out of the way, I can now run Helm to get everything installed. Helm uses a values file and this is just a YAML file with configurations for the installation. Let's take a closer look at the one I'll be using. At the top, there's some information about the Docker image and the version of Twi. This will be pulled from the public DockerHub repository. Further down is an ingress section. This defines how the registry will be exposed outside of Kubernetes. I'll be using a domain name called registry.heavy at heavy metalcloud.land, and I'll be securing that domain with TLS. The secret here contains the public and private key that I set up earlier. Further down, we have a persistent section. In my last video about shared services, I talked about persistent storage in Kubernetes. I'll be using the Longhorn storage class that I set up in the previous video. Basically, the Docker images have to be stored somewhere. So, I'll be storing them as files in the Longhorn storage system. Finally, there's a secret section. The important entry here is HT password. This is where you pass the encoded username and password from a previous step. All right, there's one more section I want to show you. Under the config data block, you have the option to add a proxy. This will allow you to mirror public container registries and effectively act as a pass through with some caching. In this case, I'm mirroring a Docker repo. Okay, with the values file configured, let's run the helm command to make sure that worked. I'll run a few cube cuddle commands. And here you can see the pod that was created. And this is what's actually running the container registry. This command shows the ingress along with the connection information. From a storage perspective, these are the Kubernetes objects that will handle persistence. The higher level abstraction is called a PVC and the low-level storage is a PV or persistent volume. Now, let's make sure everything is working. I'll hop on my laptop, then grab an EngineX image from a public docker hub repository. To access my trun service, I'll first have to log in. Then I'll tag the enginex image so that it points to my registry and then push it up. To test, we can use an endpoint that truin exposes as a web page. If everything is working, we should be able to see the EngineX image from the browser. And there it is. All right, my first shared service is installed and ready to go. In my next video, I'll install the next service called Open LDAP that I'll use to manage user accounts in my cloud. Thanks for stopping by and I'll see you in the next video.

Video description

In this video, I’m setting up Twuni, a private container registry, as a shared service on my Proxmox and Kubernetes cluster. We’ll walk through why you need a local registry to keep your container images in-house, how to handle authentication with Apache HTTP tools, and how to secure everything with TLS and Longhorn persistent storage. 🔔 **Subscribe** for more hands‑on cloud tutorials! *To follow along, check out my GitHub page! All the commands and instructions from this video are in a README file:* *https://github.com/heavy-metal-cloud/youtube/tree/main/videos/build-your-own-cloud-series/07-container-registry/twuni* 00:00:00 - Intro 00:02:11 - Creating Auth Credentials & K8s Secrets 00:03:01 - Helm Values for Twuni 00:03:48 - Persistent Storage with Longhorn 00:04:58 - Testing: Pushing your first Nginx image Links referenced in this video: https://github.com/twuni/docker-registry.helm https://hub.docker.com/ https://quay.io/ https://httpd.apache.org/docs/current/programs/htpasswd.html Amazon Affiliate Links - The Cloud Hardware: https://amzn.to/49GQo81 https://amzn.to/48c5nUT https://amzn.to/48bkX38 https://amzn.to/43Qeh9o https://amzn.to/43J6TfV https://amzn.to/4p7dsBx

© 2026 GrayBeam Technology Privacy v0.1.0 · ac93850 · 2026-04-03 22:43 UTC