Flag</th>	ENV</th>	Subcommands</th></tr></thead>
`--deployment</code></td>`	`K8S_SCALE_DEPLOYMENT</code></td>`	both</td></tr>
`--namespace</code></td>`	`K8S_SCALE_NAMESPACE</code></td>`	both</td></tr>
`--replicas</code></td>`	`K8S_SCALE_REPLICAS</code></td>`	scale</td></tr>
`--dry-run</code></td>`	`K8S_SCALE_DRY_RUN</code></td>`	both</td></tr>
`--extra-ca-bundle</code></td>`	`K8S_SCALE_EXTRA_CA_BUNDLE</code></td>`	both</td></tr> </tbody></table> The `--namespace</code> flag exists, but the CronJob does not hardcode it. Instead, the pod reads its own namespace from the Downward API and passes it through as an environment variable. That keeps the ServiceAccount’s Role safely namespace-scoped: the tool can only ever act on Deployments in the namespace where the CronJob itself runs. Not a general-purpose “scale anything anywhere” tool.</p>` Design highlights🔗</a></h2> Minimal RBAC via the scale</code> subresource🔗</a></h3> Setting replicas does not need patch</code> on the full Deployment. Kubernetes exposes deployments/scale</code> as a dedicated subresource:</p> r</span>ules</span>:</span></span> -</span> a</span>piGroups</span>:</span> [</span>"</span>apps</span>"</span>]</span></span> r</span>esources</span>:</span> [</span>"</span>deployments/scale</span>"</span>]</span></span> v</span>erbs</span>:</span> [</span>"</span>get</span>"</span>,</span> "</span>patch</span>"</span>,</span> "</span>update</span>"</span>]</span></span></code></pre> That is all the scale mode needs. Restart mode does need patch</code> on deployments</code> itself (to update the pod template annotation), so the shipped Role covers both:</p> -</span> a</span>piGroups</span>:</span> [</span>"</span>apps</span>"</span>]</span></span> r</span>esources</span>:</span> [</span>"</span>deployments</span>"</span>]</span></span> v</span>erbs</span>:</span> [</span>"</span>get</span>"</span>,</span> "</span>patch</span>"</span>]</span></span></code></pre> patch</code> on the full Deployment is broader than patch</code> on deployments/scale</code> — RBAC review at deploy time should factor that in when the CronJob is configured for restart mode.</p> Extra-CA bundle merged into the trust store🔗</a></h3> The kube client uses the in-cluster CA from the ServiceAccount token secret automatically. For clusters whose API server certificate is signed by a corporate CA that is not in the SA-mounted ca.crt</code>, --extra-ca-bundle <path></code> reads a PEM file (or a full chain of them) and appends every CERTIFICATE</code> block to kube::Config.root_cert</code>. Non-certificate blocks in the file are filtered out.</p> Rendered in Helm as an optional ConfigMap mount; in Kustomize as an opt-in Component. Neither path forces the mount when there is no corporate CA to add.</p> The rustls 0.23 CryptoProvider gotcha🔗</a></h3> If you build against kube-rs</code> with the rustls-tls</code> feature on the current release, the binary compiles cleanly — and then panics at the first TLS handshake with:</p> Could not automatically determine the process-level CryptoProvider from Rustls crate features</span></span></code></pre> rustls</code> 0.23 no longer picks a crypto backend based on downstream feature flags. The application itself must call rustls::crypto::ring::default_provider().install_default()</code> before any TLS work happens. In k8s-scale-app-rs this runs as the first step in main()</code>.</p> Two notes for anyone hitting the same wall: the panic never fires at compile time, and no test caught it locally because integration tests without a cluster do not open a TLS connection. It only surfaces when the CronJob actually tries to reach the API server.</p> Two deploy paths, independent🔗</a></h3> Helm and Kustomize both ship in the repo, and either can be used on its own:</p> Helm chart</strong> with values-{dev,preprod,prod}.yaml</code>, a mode: scale \| restart</code> toggle that swaps the subcommand argument and drops the unused replicas env, and serviceAccount.create</code> / rbac.create</code> / extraCA.enabled</code> toggles for the pieces that a given cluster may or may not need.</li> Kustomize</strong> with a base that has only the CronJob, plus three opt-in Components (serviceaccount/</code>, rbac/</code>, extra-ca/</code>) that overlays include as needed. Overlays under overlays/{dev,preprod,prod}/</code> set namespace and image tag and a patch that touches only the fields that vary per stage.</li> </ul> No Helm-inside-Kustomize glue, no Kustomize-on-Helm-render. Whichever tool matches an existing pipeline is the one to use.</p> Two container images🔗</a></h2> The default image and a -debug</code> variant, both built in the same GitHub Actions matrix — the production/-debug</code> split itself is a general pattern, covered in more depth in Part 2 of the K8s/OpenShift Best Practices series</a>:</p> File</th> Base</th> Contents</th> Approx. size</th></tr></thead> Containerfile</code></td> registry.access.redhat.com/ubi10/ubi-micro</code></td> Binary + CA trust store + /licenses/</code>, no package manager</td> ≈35 MB</td></tr> Containerfile.debug</code></td> registry.access.redhat.com/ubi10/ubi-minimal</code></td> Everything above + bash</code>, curl</code>, bind-utils</code> (dig</code>)</td> ≈115 MB</td></tr> </tbody></table> ubi10-micro</code> is not fully distroless in the Google sense — bash and coreutils are still there — but it has no package manager and no network tools, which fits the pod’s actual operational surface for a scheduled scale or restart call. The -debug</code> variant exists for the day a pod loops in ImagePullBackOff</code> or a network policy silently drops the API-server traffic and someone needs to kubectl exec</code> in with tools to check.</p> Why UBI10🔗</a></h3> The base itself, not just the two variants built from it, was a deliberate choice. I went with Red Hat’s UBI over an Alpine or a generic Docker Hub base image for one reason: it gives the image a level of maintenance stability I don’t have to police myself — CVE scanning and rebuilds are Red Hat’s job, not something I track on my own. That comes with a tradeoff worth stating plainly: UBI is not “digitally sovereign” in the sense the upcoming Digital Sovereignty in Practice series covers — it is a US vendor’s supply chain, the same as pulling from Docker Hub or almost any other public registry would be. I did not find a base that solved that concern without giving up the maintenance guarantees I wanted, so UBI10 here is a compromise I made deliberately, not a claim that the underlying problem is solved.</p> Both images ship an aggregated /licenses/LICENSES.txt</code> bundled with cargo-about</code> during the container build, generated from a whitelist of accepted SPDX identifiers. A new dependency that pulls in an unfamiliar license fails the container build on purpose.</p> Supply chain🔗</a></h2> The build-publish workflow</a> runs three jobs on every push, plus a release job on tag pushes:</p> test</code></strong> — cargo fmt --check</code>, cargo clippy -D warnings</code>, cargo test --release</code>. Cluster tests auto-skip in CI (no KUBECONFIG</code>, no in-cluster SA token).</li> build-image</code></strong> — matrix over Containerfile</code> and Containerfile.debug</code>. Each variant is built with buildx, pushed to ghcr.io/git001/k8s-scale-app-rs</code>, smoke-tested (--version</code>, scale --help</code>, restart --help</code>), then: signed with cosign keyless</strong> via the GitHub OIDC token (no key management — Fulcio issues a short-lived certificate, the signature is logged to Rekor);</li> has an SPDX-JSON SBOM</strong> generated with syft and attached via cosign attest --type spdxjson</code>;</li> has SLSA build provenance</strong> pushed with actions/attest-build-provenance</code>.</li> </ul> </li> publish-chart</code></strong> — helm lint</code> and helm package</code> on every push; OCI push to oci://ghcr.io/git001/charts/k8s-scale-app-rs</code>, plus cosign sign and SLSA provenance only on tag events (avoids overwrite conflicts on GHCR-immutable tags).</li> release</code></strong> (tag events only) — creates the GitHub Release with auto-generated notes from commits since the previous tag, attaches the packaged chart .tgz</code> as an asset, and prepends the release body with pull and verify snippets.</li> </ol> All of that runs with permissions: contents:read, packages:write, id-token:write, attestations:write</code> — the minimum needed for OIDC-based signing plus attestation upload.</p> Verifying a published image🔗</a></h2> A consumer that wants to check what came out of that pipeline needs cosign v2:</p> IMG</span>=</span>g</span>h</span>c</span>r</span>.</span>i</span>o</span>/</span>g</span>i</span>t</span>0</span>0</span>1</span>/</span>k</span>8</span>s</span>-</span>s</span>c</span>a</span>l</span>e</span>-</span>a</span>p</span>p</span>-</span>r</span>s</span>:</span>v</span>1</span>.</span>0</span>.</span>0</span></span> IDENTITY</span>=</span>'</span>^https://github.com/git001/k8s-scale-app-rs/</span>'</span></span> ISSUER</span>=</span>h</span>t</span>t</span>p</span>s</span>:</span>/</span>/</span>t</span>o</span>k</span>e</span>n</span>.</span>a</span>c</span>t</span>i</span>o</span>n</span>s</span>.</span>g</span>i</span>t</span>h</span>u</span>b</span>u</span>s</span>e</span>r</span>c</span>o</span>n</span>t</span>e</span>n</span>t</span>.</span>c</span>o</span>m</span></span> </span> cosign</span> verify</span> \</span></span> -</span>-certificate-identity-regexp</span> "</span>$</span>IDENTITY</span>"</span> \</span></span> -</span>-certificate-oidc-issuer</span> "</span>$</span>ISSUER</span>"</span> \</span></span> "</span>$</span>IMG</span>"</span></span> </span> cosign</span> verify-attestation</span> -</span>-type</span> spdxjson</span> \</span></span> -</span>-certificate-identity-regexp</span> "</span>$</span>IDENTITY</span>"</span> \</span></span> -</span>-certificate-oidc-issuer</span> "</span>$</span>ISSUER</span>"</span> \</span></span> "</span>$</span>IMG</span>"</span></span> </span> cosign</span> verify-attestation</span> -</span>-type</span> slsaprovenance</span> \</span></span> -</span>-certificate-identity-regexp</span> "</span>$</span>IDENTITY</span>"</span> \</span></span> -</span>-certificate-oidc-issuer</span> "</span>$</span>ISSUER</span>"</span> \</span></span> "</span>$</span>IMG</span>"</span></span></code></pre> For enforcement inside the cluster, a cosign-aware admission controller — Kyverno</a>, Sigstore policy-controller</a>, or Connaisseur</a> — can turn the signature into a hard gate that rejects any pod trying to pull an image that was not produced by exactly this workflow. That is a separate deployment concern; the tool repo does not ship the policy itself.</p> Mirroring the image into another registry🔗</a></h2> Verifying a signature only works if the signature actually travels with the image. Not every docker pull && docker push</code>-style mirroring tool preserves it — some tools do, some quietly drop it, and one (oc-mirror v2</code>) solves a related but entirely different signature problem. I wrote up a full, sourced comparison — Which Tool Mirrors a Cosign-Signed Image into a Private Registry?</a> — with regctl</code> coming out as the most complete option for this specific image.</p> Code and repository🔗</a></h2> Repository: k8s-scale-app-rs on GitHub</a></li> Container images: ghcr.io/git001/k8s-scale-app-rs:v1.0.0</code> and ghcr.io/git001/k8s-scale-app-rs:v1.0.0-debug</code></li> Helm chart: oci://ghcr.io/git001/charts/k8s-scale-app-rs:1.0.0</code></li> </ul> Feedback and PRs welcome.</p> Which Tool Mirrors a Cosign-Signed Image into a Private Registry? aleks — Mon, 06 Jul 2026 00:00:00 +0000 TL;DR🔗</a></h2> regctl</code> is the most complete option — it exposes the legacy tag-based signature scheme and the modern OCI 1.1 referrers API as two separate, explicit flags. oras cp -r</code> is the second choice, and the tool cosign’s own project points to now that cosign copy</code> is deprecated. oc-mirror v2</code> looks like it should be on this list but actually solves a different, unrelated signature problem.</p> The problem🔗</a></h2> Verifying a signature only works if the signature actually travels with the image. Anyone mirroring a Cosign-signed image into a private or air-gapped registry needs the copy step itself to carry the signature along, not just the layers — and that is not automatic. Some tools drop it silently, some need a config flag turned on first, and one widely-used tool solves a related but entirely different problem. k8s-scale-app-rs</a> is the worked example throughout this post — its own container images are signed keylessly with cosign, carry an SBOM and SLSA build provenance, and its “Verifying a published image”</a> section shows what verification actually checks. This post is about what happens before</em> verification: getting the signature into the registry the verifier will actually query.</p> A short, sourced comparison, checked directly against each project’s docs/source (as of July 2026):</p> A naming trap worth knowing first🔗</a></h2> Red Hat’s oc-mirror v2</code> — the tool for mirroring into disconnected OpenShift installs — has its own --secure-policy</code>/--remove-signatures</code>/--registries.d</code> flags, but they implement Red Hat’s older “simple signing” scheme: a policy.json</code> plus GPG keys plus an external sigstore:</code> URL (e.g. mirror.openshift.com/pub/openshift-v4/signatures</code> for OpenShift release images). That predates, and has nothing to do with, the CNCF Sigstore project this post’s cosign workflow uses — same word, unrelated mechanism. oc-mirror v2</code> went GA in OpenShift 4.18 (release notes</a>), but its ImageSetConfiguration</code> API is still v2alpha1</code>, and none of Red Hat’s own walkthroughs for it touch Cosign-style signatures at all.</p> Tool comparison🔗</a></h2> Tool</th> Legacy tag-based signature (sha256-<digest>.sig</code>)</th> OCI 1.1 referrers (modern Cosign/SBOM/attestations)</th> Note</th></tr></thead> regctl image copy</code></a></td> --digest-tags</code></td> --referrers</code></td> only tool here with separate, explicit flags for both schemes</td></tr> oras cp -r</code></a></td> via -r</code></td> -r</code> (marked “Preview”)</td> --from/to-distribution-spec</code> handles referrers-tag vs. referrers-API mismatches between registries</td></tr> skopeo copy</code></td> opt-in</td> not supported</td> needs use-sigstore-attachments: true</code> under the default-docker</code> key in registries.d</code>, on both source and destination</td></tr> Zot registry sync</code></td> syncLegacyCosignTags</code> (default true</code>)</td> only with preserveDigest: true</code></td> without preserveDigest</code>, Zot re-encodes Docker-format images to OCI on sync, which changes the digest and detaches the signature</td></tr> cosign copy</code></td> yes</td> no</td> deprecated</strong> as of sigstore/cosign#4681</a> (merged 2026-02-04) — the tool itself now points to oras copy -r</code> instead</td></tr> crane copy</code></td> only incidentally, via --all-tags</code></td> no</td> plain manifest/layer copier, no signature awareness at all</td></tr> Harbor replication</td> per Harbor’s own docs, yes</td> open gap (goharbor/harbor#23210</a>)</td> works for the legacy scheme; OCI 1.1 referrers replication is not yet reliable</td></tr> </tbody></table> regctl</code> is the only tool in this comparison that exposes both signature schemes as distinct, intentional flags rather than as a side effect of copying “everything.” For a registry pair that already speaks the OCI 1.1 referrers API end to end, oras cp -r</code> is the other option worth checking — it’s what the cosign project’s own deprecation notice for cosign copy</code> points to.</p> Example: mirroring with regctl🔗</a></h2> Here is an example command to mirror k8s-scale-app-rs</code> itself, signature included, using regctl</code>:</p> regctl</span> image</span> copy</span> \</span></span> -</span>-digest-tags</span> -</span>-referrers</span> \</span></span> ghcr.io/git001/k8s-scale-app-rs:v1.0.0</span> \</span></span> my-private-registry.example.com/k8s-scale-app-rs:v1.0.0</span></span></code></pre>Sources🔗</a></h2> sigstore/cosign PR #4681 — “Deprecate cosign copy”</a></li> sigstore/cosign#4335 — Complete OCI 1.1 Referrers API Support Across All Cosign Commands</a></li> sigstore/cosign#4564 — cosign verify fails after cosign copy (JFrog Artifactory)</a></li> podman-container-tools/skopeo#2061 — sigstore signature copying and use-sigstore-attachments</code></a></li> regctl image copy</code> reference</a></li> oras cp</code> command reference</a></li> goharbor/harbor#23210 — OCI 1.1 referrers not replicated</a></li> Zot registry: mirroring/sync documentation</a></li> OpenShift Container Platform 4.18 release notes</a></li> openshift/oc-mirror — signature-verification.md</a></li> </ul> What is a (D)DoS - technical aleks — Sat, 20 Jun 2026 00:00:00 +0000 The technical follow-up to the non-technical (D)DoS overview</a>. Covers Layer 3/4 network floods (SYN, UDP, amplification), BGP hijacking, Layer 7 application DDoS, and operational resilience — all focused on availability.</p> Originally published at opensourcerers.org</a>; updated with current attack vectors and technologies.</p> What is a (D)DoS aleks — Sat, 20 Jun 2026 00:00:00 +0000 (D)DoS attacks are not just a technical problem — they operate at the Business, Social, and Informational level as well. This post covers the non-technical dimensions; the technical follow-up</a> covers Layer 3/4 network floods, BGP hijacking, TLS handshake attacks, Layer 7 application DDoS, and operational resilience.</p> Originally published at opensourcerers.org</a>; updated with current examples and expanded framing.</p> (D)DoS and Application Security: The Complete Guide aleks — Fri, 19 Jun 2026 00:00:00 +0000 This is the index and reading guide for a three-part series on denial-of-service and application security. The first two parts cover availability</strong> attacks — a service being made unreachable or unusable — at levels most people don’t associate with the term “DDoS”: the business level (losing the people who run the service), the social level (manipulating the humans behind it), the informational level (reputational disruption), and finally the technical level most readers expect (network floods, BGP hijacking, Layer 7 exhaustion). The third part is a deliberate step sideways, into application-layer attacks — SQL Injection, Log4Shell, the OWASP Top 10 — that threaten confidentiality and integrity</strong> instead of availability.</p> How I work with Claude Code aleks — Wed, 10 Jun 2026 00:00:00 +0000 Since 2025, I have been using AI tools as part of my daily work. Not as a replacement for thinking — as a productivity aid. An AI coding agent has become a regular part of how I work on infrastructure, blog posts, and software projects. Most of what follows likely applies to other agents as well — Cursor, Copilot, or whatever comes next. I happen to use Claude.</p> This post is not a tutorial and not a pitch. It is a reflection on what actually works — for me, on my projects — across months of real use, across 40+ projects, and across months of agent use.</p> LLM Inference on OVH MKS: Connect IDEs and Web UIs aleks — Tue, 02 Jun 2026 00:00:00 +0000 The first four parts of this series deployed a vLLM inference endpoint at https://llm.YOUR_DOMAIN/v1</code>, protected by a Bearer token, running on an OVH RTX5000-28 GPU node. This part shows how to connect coding assistants, web UIs, and other OpenAI-compatible clients to that endpoint.</p> LLM Inference on OVH MKS: Terraform, Ansible, and Deployment aleks — Tue, 02 Jun 2026 00:00:00 +0000 Part 1</a> covered the architecture and use cases. This post walks through the complete Terraform and Ansible setup and a first deployment.</p> LLM Inference on OVH MKS: LiteLLM API Gateway aleks — Tue, 02 Jun 2026 00:00:00 +0000 Parts 1–5 deployed a functional self-hosted LLM endpoint. This part adds LiteLLM</a> — an open-source proxy that exposes a unified OpenAI-compatible API across multiple LLM backends — in front of vLLM. The gateway layer brings per-user API keys, budget enforcement, and automatic fallback to commercial APIs when the local model is unavailable.</p> LLM Inference on OVH MKS: The Complete Guide aleks — Tue, 02 Jun 2026 00:00:00 +0000 This is the index and reading guide for a six-part series on self-hosting LLM inference on a GPU-enabled Kubernetes node pool, using OVH Managed Kubernetes Service (MKS) as the concrete platform throughout. The series runs end to end: the decision of whether to self-host at all, provisioning the GPU infrastructure, serving a model behind an OpenAI-compatible API, wiring up observability and autoscaling, connecting real client tools, and finally putting a multi-user gateway in front of the whole thing.</p> LLM Inference on OVH MKS: Introduction aleks — Tue, 02 Jun 2026 00:00:00 +0000 This post covers the decision context for self-hosting LLM inference on OVH MKS: when it makes sense, what the stack looks like, and what the costs are. Part 2</a> walks through the Terraform and Ansible setup.</p> LLM Inference on OVH MKS: Prometheus, Grafana, and KEDA aleks — Tue, 02 Jun 2026 00:00:00 +0000 Part 1</a> covered the architecture and use cases. Part 2</a> walked through Terraform and Ansible. Part 3</a> covered models and the OpenAI API. This part adds observability (Prometheus + Grafana) and scale-to-zero autoscaling via KEDA.</p> LLM Inference on OVH MKS: Models, AWQ, and OpenAI API aleks — Tue, 02 Jun 2026 00:00:00 +0000 Part 1</a> covered the architecture and use cases. Part 2</a> walked through the Terraform and Ansible setup. This post covers which models fit on the RTX5000-28’s 16 GB GPU VRAM, why AWQ quantization is required for 7B+ models, and how to use the OpenAI-compatible endpoint from your own code.</p> SigNoz on OVH MKS: Access Log Reports with Vector and ClickHouse aleks — Mon, 18 May 2026 00:00:00 +0000 Posts 1</a> and 2</a> of this series set up the SigNoz observability stack on OVH MKS and demonstrated metrics, traces, and Kubernetes pod log collection. This post adds a practical use case: structured Envoy access log collection via Vector, archiving to OVH Object Storage in Combined Log Format, and monthly HTML reports via awffull — accessible at https://reports.<your-domain></code> through the existing Istio gateway.</p> SigNoz on OVH MKS: The Complete Guide aleks — Sat, 16 May 2026 00:00:00 +0000 This is the index and reading guide for a three-part series that turns storage-engine theory into a fully reproducible, sovereign observability stack: SigNoz</a> Community Edition on OVH Managed Kubernetes Service (MKS), with metrics, distributed traces, and logs all stored in a single ClickHouse cluster and cold-tiered to OVH Object Storage Infrequent Access. It is an alternative to hyperscaler-locked observability SaaS, built as a working example repository rather than a slide deck — clone it, fill in credentials, run Terraform and Ansible. Unlike a stack that bolts together Prometheus, Jaeger or Tempo, and Loki or Elasticsearch as three separately-operated databases, SigNoz stores metrics, traces, and logs together in ClickHouse from the start — one retention policy, one S3 tiering config, one SQL interface, instead of three.</p> SigNoz on OVH MKS: Infrastructure with Terraform + Ansible aleks — Sat, 16 May 2026 00:00:00 +0000 The previous two series covered the theory: which storage engine fits 7-year log archiving</a> and what managed cloud services cost</a>. This post turns that analysis into a fully reproducible sovereign observability stack. The goal is not just lower cost, but operational control and EU-hosted observability without hyperscaler lock-in — SigNoz</a> Community Edition on OVH, with metrics, distributed traces, and logs all stored in ClickHouse with S3 cold-tier tiering to OVH Object Storage Infrequent Access.</p> SigNoz on OVH MKS: Metrics, Traces & Logs with Istio Ambient aleks — Sat, 16 May 2026 00:00:00 +0000 Part 1</a> set up the infrastructure: OVH MKS, vRack, Istio Ambient Mode, and SigNoz itself via Terraform + Ansible. This post covers what to do after the cluster is running — sending telemetry data, verifying the S3 cold tier is active, and building the first dashboards.</p> Running pdns_recursor as a root-independent validating resolver aleks — Mon, 06 Apr 2026 00:00:00 +0000 PowerDNS Recursor</a> is a mature, production-grade recursive DNS resolver. This post documents how to configure it to bootstrap directly from a local root.zone</code> file — so it never needs to reach the root name servers at runtime — with full DNSSEC validation producing the ad</code> flag in responses.</p> Running a validating DNS recursor from the root zone with Hickory DNS aleks — Sat, 04 Apr 2026 00:00:00 +0000 Hickory DNS</a> is a Rust-based DNS implementation that covers the full stack: resolver, recursor, authoritative server, and DNSSEC. This post documents how to run it as a full recursive resolver</strong> — starting directly from the root zone, with DNSSEC validation and encrypted upstream transport — based on the changes developed in the recurser-from-root-zone</code></a> branch.</p> vigil-log-relay: Kubernetes Log Collection Without a DaemonSet aleks — Sun, 22 Mar 2026 00:00:00 +0000 Every team running workloads on Kubernetes eventually faces the same question: how do you get logs out of your pods and into your log aggregation stack? The standard answer is a DaemonSet. It works, but it comes with a cost. vigil-log-relay</a></strong> is a different answer.</p> vigil-rs: A Rust Service Supervisor for Containers aleks — Sat, 21 Mar 2026 00:00:00 +0000 Every container that runs more than one process needs a supervisor. Most reach for dumb-init</code>, tini</code>, s6-overlay</code>, or supervisord</code>. None of them felt quite right for what we needed, so we wrote vigil-rs</strong>.</p> This post walks through what github.com/git001/vigil-rs</a> is, why we built it, and how it works internally.</p> tls-proxy-tunnel: Transparent TLS Tunnelling Through Corporate HTTP Proxies aleks — Tue, 02 Jul 2024 00:00:00 +0000 Many enterprise networks sit behind a corporate HTTP CONNECT proxy. Applications that speak TLS natively — think git</code>, curl</code>, SSH-over-HTTPS, or any custom binary — often have no built-in proxy support. Configuring every single tool is tedious, fragile, and sometimes impossible when you don’t control the binary.</p> tls-proxy-tunnel</code> (tpt</code>) solves this at layer 4: it sits between your application and the outside world, intercepts the TLS connection, extracts the Server Name Indication (SNI) from the ClientHello, and tunnels the raw bytes through your corporate HTTP CONNECT proxy — without ever terminating TLS.</p> Building a native file upload handler for Caddy v2 aleks — Tue, 01 Mar 2022 00:00:00 +0000 When Caddy v2</a> was released in 2020, it introduced a new concept of handlers that use Go’s native module features.</p> In 2022 one of our customers needed to upload files, and at that time none of the available web servers could handle this natively without an extra program. So I decided to create a new handler for Caddy v2 — caddyv2-upload</a> was born.</p> I was not aware of any other tool which can handle file uploads natively in just one binary which can be used in Kubernetes or OpenShift, or I have not searched hard enough 😁. I also wanted to learn go, so I decided to create a new handler for the go based webserver caddyserver</a>.</p> In May 2022 dufs</a>, a Rust-based server, was created — so that might be another option worth considering. 🤷</p> Any how I wanted to learn go in the pre AI Area and at that time I looked into the docs of go modules, into the source of caddy servers own handlers and created step by step a new handler.</p> Luckily there was already podman and buildah, so I was able to create container images to run and test locally.</p> Building something real turned out to be the most effective way to learn Go. Diving into Caddy’s own handler source code, understanding the module system, and iterating with containers made the concepts stick far better than any tutorial would have.</p> A minimal Caddyfile configuration looks like this:</p> {</span></span> order upload before file_server</span></span> }</span></span> </span> :2015 {</span></span> root .</span></span> </span> file_server browse</span></span> </span> @mypost method POST</span></span> upload @mypost {</span></span> dest_dir /var/uploads</span></span> max_filesize 4MB</span></span> }</span></span> }</span></span></code></pre> Build with xcaddy</a>:</p> xcaddy</span> build</span> -</span>-with</span> github.com/git001/caddyv2-upload</span></span></code></pre> Today caddyv2-upload</a> (v0.20.0) supports file uploads via HTTP multipart form, configurable destination directories, UUID-based subdirectory creation per upload, fixed filenames, pass-through mode to continue to the next Caddy handler after upload, configurable file size limits, an HTTP notification callback after successful uploads, and a /health</code> endpoint. It integrates with Caddy’s variable system and works in Kubernetes and OpenShift environments. Authentication is handled by Caddy’s own security layer rather than the module itself.</p> How does SNI Routing work in HAProxy aleks — Fri, 17 May 2019 00:00:00 +0000 As I travel a lot I faced the problem that in some Wi-Fi networks certain ports are blocked for outgoing communication 😱. The solution is to use software that can handle TCP and HTTP via port 443</strong> so that I can use my Nextcloud and my XMPP client on the same port.</p>

k8s-scale-app-rs: Scale or Restart a Kubernetes Deployment from a CronJob

aleks — Mon, 06 Jul 2026 00:00:00 +0000

restart</code></strong> — patches the pod template’s restartedAt</code> annotation, which is the same mechanism kubectl rollout restart</code> uses.</li> </ul> Designed to run as a CronJob</code>. Version 1.0.0 is published; container images and the Helm chart are on ghcr.io</code>, signed with cosign (keyless via GitHub OIDC), and shipped with an SPDX SBOM plus SLSA build provenance.</p>

Why I built it🔗</a></h2>
The classic way to “run kubectl scale</code> on a schedule in a cluster” is to put a kubectl</code> binary into a Job image. That works, but it drags in a few things I did not want:</p>

The full kubectl</code> binary (about 50 MB stripped) for one API call.</li>
A kubeconfig / ServiceAccount plumbing that is broader than the one operation actually needs.</li>
Enough YAML around the pod spec to hide the actual behavior behind a template.</li>
</ul>
A purpose-built tool is a natural fit for Rust here: a single self-contained binary — no OpenSSL, no runtime dependency beyond glibc and the CA trust store — and a ServiceAccount that only needs deployments/scale: patch</code>. That is what k8s-scale-app-rs is.</p>
KEDA and Argo Workflows solve a related but different problem — reacting to events or orchestrating multi-step pipelines — not “flip a replica count or a restart annotation on a fixed schedule.” KEDA in particular has its own well-known scale-from-zero gap: a Prometheus-metric trigger can scale 1→N but not 0→1, because a Deployment at zero replicas emits no metric to react to (see the LLM inference series</a> for the concrete failure mode). None of that machinery applies here — a CronJob calling a purpose-built binary on a fixed schedule has nothing to react to.</p>
The same binary also covers restart. kubectl rollout restart deployment/foo</code> under the hood is one patch on spec.template.metadata.annotations["kubectl.kubernetes.io/restartedAt"]</code>. Two subcommands, same binary, same image.</p>
What it does🔗</a></h2>
The CLI is two subcommands sharing common arguments:</p>
k8s-scale-app-rs scale   --deployment <NAME> --replicas <N> [--dry-run] [--extra-ca-bundle <PATH>]</span></span>
k8s-scale-app-rs restart --deployment <NAME>                [--dry-run] [--extra-ca-bundle <PATH>]</span></span></code></pre>
Configuration is via environment variables, overridable by CLI flags:</p>
Flag</th> ENV</th> Subcommands</th></tr></thead>

--deployment</code></td> K8S_SCALE_DEPLOYMENT</code></td> both</td></tr>
--namespace</code></td> K8S_SCALE_NAMESPACE</code></td> both</td></tr>
--replicas</code></td> K8S_SCALE_REPLICAS</code></td> scale</td></tr>
--dry-run</code></td> K8S_SCALE_DRY_RUN</code></td> both</td></tr>
--extra-ca-bundle</code></td> K8S_SCALE_EXTRA_CA_BUNDLE</code></td> both</td></tr>
</tbody></table>
The --namespace</code> flag exists, but the CronJob does not hardcode it. Instead, the pod reads its own namespace from the Downward API and passes it through as an environment variable. That keeps the ServiceAccount’s Role safely namespace-scoped: the tool can only ever act on Deployments in the namespace where the CronJob itself runs. Not a general-purpose “scale anything anywhere” tool.</p>
Design highlights🔗</a></h2>
Minimal RBAC via the scale</code> subresource🔗</a></h3>
Setting replicas does not need patch</code> on the full Deployment. Kubernetes exposes deployments/scale</code> as a dedicated subresource:</p>
r</span>ules</span>:</span></span>
  -</span> a</span>piGroups</span>:</span> [</span>"</span>apps</span>"</span>]</span></span>
    r</span>esources</span>:</span> [</span>"</span>deployments/scale</span>"</span>]</span></span>
    v</span>erbs</span>:</span> [</span>"</span>get</span>"</span>,</span> "</span>patch</span>"</span>,</span> "</span>update</span>"</span>]</span></span></code></pre>
That is all the scale mode needs. Restart mode does need patch</code> on deployments</code> itself (to update the pod template annotation), so the shipped Role covers both:</p>
  -</span> a</span>piGroups</span>:</span> [</span>"</span>apps</span>"</span>]</span></span>
    r</span>esources</span>:</span> [</span>"</span>deployments</span>"</span>]</span></span>
    v</span>erbs</span>:</span> [</span>"</span>get</span>"</span>,</span> "</span>patch</span>"</span>]</span></span></code></pre>
patch</code> on the full Deployment is broader than patch</code> on deployments/scale</code> — RBAC review at deploy time should factor that in when the CronJob is configured for restart mode.</p>
Extra-CA bundle merged into the trust store🔗</a></h3>
The kube client uses the in-cluster CA from the ServiceAccount token secret automatically. For clusters whose API server certificate is signed by a corporate CA that is not in the SA-mounted ca.crt</code>, --extra-ca-bundle <path></code> reads a PEM file (or a full chain of them) and appends every CERTIFICATE</code> block to kube::Config.root_cert</code>. Non-certificate blocks in the file are filtered out.</p>
Rendered in Helm as an optional ConfigMap mount; in Kustomize as an opt-in Component. Neither path forces the mount when there is no corporate CA to add.</p>
The rustls 0.23 CryptoProvider gotcha🔗</a></h3>
If you build against kube-rs</code> with the rustls-tls</code> feature on the current release, the binary compiles cleanly — and then panics at the first TLS handshake with:</p>
Could not automatically determine the process-level CryptoProvider from Rustls crate features</span></span></code></pre>
rustls</code> 0.23 no longer picks a crypto backend based on downstream feature flags. The application itself must call rustls::crypto::ring::default_provider().install_default()</code> before any TLS work happens. In k8s-scale-app-rs this runs as the first step in main()</code>.</p>
Two notes for anyone hitting the same wall: the panic never fires at compile time, and no test caught it locally because integration tests without a cluster do not open a TLS connection. It only surfaces when the CronJob actually tries to reach the API server.</p>
Two deploy paths, independent🔗</a></h3>
Helm and Kustomize both ship in the repo, and either can be used on its own:</p>

Helm chart</strong> with values-{dev,preprod,prod}.yaml</code>, a mode: scale | restart</code> toggle that swaps the subcommand argument and drops the unused replicas env, and serviceAccount.create</code> / rbac.create</code> / extraCA.enabled</code> toggles for the pieces that a given cluster may or may not need.</li>
Kustomize</strong> with a base that has only the CronJob, plus three opt-in Components (serviceaccount/</code>, rbac/</code>, extra-ca/</code>) that overlays include as needed. Overlays under overlays/{dev,preprod,prod}/</code> set namespace and image tag and a patch that touches only the fields that vary per stage.</li>
</ul>
No Helm-inside-Kustomize glue, no Kustomize-on-Helm-render. Whichever tool matches an existing pipeline is the one to use.</p>
Two container images🔗</a></h2>
The default image and a -debug</code> variant, both built in the same GitHub Actions matrix — the
production/-debug</code> split itself is a general pattern, covered in more depth in
Part 2 of the K8s/OpenShift Best Practices series</a>:</p>
File</th> Base</th> Contents</th> Approx. size</th></tr></thead>

Containerfile</code></td> registry.access.redhat.com/ubi10/ubi-micro</code></td> Binary + CA trust store + /licenses/</code>, no package manager</td> ≈35 MB</td></tr>
Containerfile.debug</code></td> registry.access.redhat.com/ubi10/ubi-minimal</code></td> Everything above + bash</code>, curl</code>, bind-utils</code> (dig</code>)</td> ≈115 MB</td></tr>
</tbody></table>
ubi10-micro</code> is not fully distroless in the Google sense — bash and coreutils are still there — but it has no package manager and no network tools, which fits the pod’s actual operational surface for a scheduled scale or restart call. The -debug</code> variant exists for the day a pod loops in ImagePullBackOff</code> or a network policy silently drops the API-server traffic and someone needs to kubectl exec</code> in with tools to check.</p>
Why UBI10🔗</a></h3>
The base itself, not just the two variants built from it, was a deliberate choice. I went with
Red Hat’s UBI over an Alpine or a generic Docker Hub base image for one reason: it gives the
image a level of maintenance stability I don’t have to police myself — CVE scanning and rebuilds
are Red Hat’s job, not something I track on my own. That comes with a tradeoff worth stating
plainly: UBI is not “digitally sovereign” in the sense the upcoming Digital Sovereignty in
Practice series covers — it is a US vendor’s supply chain, the same as pulling from Docker Hub
or almost any other public registry would be. I did not find a base that solved that concern
without giving up the maintenance guarantees I wanted, so UBI10 here is a compromise I made
deliberately, not a claim that the underlying problem is solved.</p>
Both images ship an aggregated /licenses/LICENSES.txt</code> bundled with cargo-about</code> during the container build, generated from a whitelist of accepted SPDX identifiers. A new dependency that pulls in an unfamiliar license fails the container build on purpose.</p>
Supply chain🔗</a></h2>
The build-publish workflow</a> runs three jobs on every push, plus a release job on tag pushes:</p>

test</code></strong> — cargo fmt --check</code>, cargo clippy -D warnings</code>, cargo test --release</code>. Cluster tests auto-skip in CI (no KUBECONFIG</code>, no in-cluster SA token).</li>
build-image</code></strong> — matrix over Containerfile</code> and Containerfile.debug</code>. Each variant is built with buildx, pushed to ghcr.io/git001/k8s-scale-app-rs</code>, smoke-tested (--version</code>, scale --help</code>, restart --help</code>), then:

signed with cosign keyless</strong> via the GitHub OIDC token (no key management — Fulcio issues a short-lived certificate, the signature is logged to Rekor);</li>
has an SPDX-JSON SBOM</strong> generated with syft and attached via cosign attest --type spdxjson</code>;</li>
has SLSA build provenance</strong> pushed with actions/attest-build-provenance</code>.</li>
</ul>
</li>
publish-chart</code></strong> — helm lint</code> and helm package</code> on every push; OCI push to oci://ghcr.io/git001/charts/k8s-scale-app-rs</code>, plus cosign sign and SLSA provenance only on tag events (avoids overwrite conflicts on GHCR-immutable tags).</li>
release</code></strong> (tag events only) — creates the GitHub Release with auto-generated notes from commits since the previous tag, attaches the packaged chart .tgz</code> as an asset, and prepends the release body with pull and verify snippets.</li>
</ol>
All of that runs with permissions: contents:read, packages:write, id-token:write, attestations:write</code> — the minimum needed for OIDC-based signing plus attestation upload.</p>
Verifying a published image🔗</a></h2>
A consumer that wants to check what came out of that pipeline needs cosign v2:</p>
IMG</span>=</span>g</span>h</span>c</span>r</span>.</span>i</span>o</span>/</span>g</span>i</span>t</span>0</span>0</span>1</span>/</span>k</span>8</span>s</span>-</span>s</span>c</span>a</span>l</span>e</span>-</span>a</span>p</span>p</span>-</span>r</span>s</span>:</span>v</span>1</span>.</span>0</span>.</span>0</span></span>
IDENTITY</span>=</span>'</span>^https://github.com/git001/k8s-scale-app-rs/</span>'</span></span>
ISSUER</span>=</span>h</span>t</span>t</span>p</span>s</span>:</span>/</span>/</span>t</span>o</span>k</span>e</span>n</span>.</span>a</span>c</span>t</span>i</span>o</span>n</span>s</span>.</span>g</span>i</span>t</span>h</span>u</span>b</span>u</span>s</span>e</span>r</span>c</span>o</span>n</span>t</span>e</span>n</span>t</span>.</span>c</span>o</span>m</span></span>
</span>
cosign</span> verify</span> \</span></span>
  -</span>-certificate-identity-regexp</span> "</span>$</span>IDENTITY</span>"</span> \</span></span>
  -</span>-certificate-oidc-issuer</span> "</span>$</span>ISSUER</span>"</span> \</span></span>
  "</span>$</span>IMG</span>"</span></span>
</span>
cosign</span> verify-attestation</span> -</span>-type</span> spdxjson</span> \</span></span>
  -</span>-certificate-identity-regexp</span> "</span>$</span>IDENTITY</span>"</span> \</span></span>
  -</span>-certificate-oidc-issuer</span> "</span>$</span>ISSUER</span>"</span> \</span></span>
  "</span>$</span>IMG</span>"</span></span>
</span>
cosign</span> verify-attestation</span> -</span>-type</span> slsaprovenance</span> \</span></span>
  -</span>-certificate-identity-regexp</span> "</span>$</span>IDENTITY</span>"</span> \</span></span>
  -</span>-certificate-oidc-issuer</span> "</span>$</span>ISSUER</span>"</span> \</span></span>
  "</span>$</span>IMG</span>"</span></span></code></pre>
For enforcement inside the cluster, a cosign-aware admission controller — Kyverno</a>, Sigstore policy-controller</a>, or Connaisseur</a> — can turn the signature into a hard gate that rejects any pod trying to pull an image that was not produced by exactly this workflow. That is a separate deployment concern; the tool repo does not ship the policy itself.</p>
Mirroring the image into another registry🔗</a></h2>
Verifying a signature only works if the signature actually travels with the image. Not every docker pull && docker push</code>-style mirroring tool preserves it — some tools do, some quietly drop it, and one (oc-mirror v2</code>) solves a related but entirely different signature problem. I wrote up a full, sourced comparison — Which Tool Mirrors a Cosign-Signed Image into a Private Registry?</a> — with regctl</code> coming out as the most complete option for this specific image.</p>
Code and repository🔗</a></h2>

Repository: k8s-scale-app-rs on GitHub</a></li>
Container images: ghcr.io/git001/k8s-scale-app-rs:v1.0.0</code> and ghcr.io/git001/k8s-scale-app-rs:v1.0.0-debug</code></li>
Helm chart: oci://ghcr.io/git001/charts/k8s-scale-app-rs:1.0.0</code></li>
</ul>
Feedback and PRs welcome.</p>


Which Tool Mirrors a Cosign-Signed Image into a Private Registry?
aleks — Mon, 06 Jul 2026 00:00:00 +0000
TL;DR🔗</a></h2>
regctl</code> is the most complete option — it exposes the legacy tag-based signature scheme and the
modern OCI 1.1 referrers API as two separate, explicit flags. oras cp -r</code> is the second choice,
and the tool cosign’s own project points to now that cosign copy</code> is deprecated. oc-mirror v2</code>
looks like it should be on this list but actually solves a different, unrelated signature problem.</p>
The problem🔗</a></h2>
Verifying a signature only works if the signature actually travels with the image. Anyone mirroring
a Cosign-signed image into a private or air-gapped registry needs the copy step itself to carry the
signature along, not just the layers — and that is not automatic. Some tools drop it silently, some
need a config flag turned on first, and one widely-used tool solves a related but entirely different
problem. k8s-scale-app-rs</a> is the worked example
throughout this post — its own container images are signed keylessly with cosign, carry an SBOM and
SLSA build provenance, and its “Verifying a published image”</a>
section shows what verification actually checks. This post is about what happens before</em>
verification: getting the signature into the registry the verifier will actually query.</p>
A short, sourced comparison, checked directly against each project’s docs/source (as of July 2026):</p>
A naming trap worth knowing first🔗</a></h2>
Red Hat’s oc-mirror v2</code> — the tool for mirroring into disconnected OpenShift installs — has its
own --secure-policy</code>/--remove-signatures</code>/--registries.d</code> flags, but they implement Red Hat’s
older “simple signing” scheme: a policy.json</code> plus GPG keys plus an external sigstore:</code> URL (e.g.
mirror.openshift.com/pub/openshift-v4/signatures</code> for OpenShift release images). That predates,
and has nothing to do with, the CNCF Sigstore project this post’s cosign workflow uses — same word,
unrelated mechanism. oc-mirror v2</code> went GA in OpenShift 4.18 (release
notes</a>),
but its ImageSetConfiguration</code> API is still v2alpha1</code>, and none of Red Hat’s own walkthroughs for
it touch Cosign-style signatures at all.</p>
Tool comparison🔗</a></h2>
Tool</th> Legacy tag-based signature (sha256-<digest>.sig</code>)</th> OCI 1.1 referrers (modern Cosign/SBOM/attestations)</th> Note</th></tr></thead>

regctl image copy</code></a></td> --digest-tags</code></td> --referrers</code></td> only tool here with separate, explicit flags for both schemes</td></tr>
oras cp -r</code></a></td> via -r</code></td> -r</code> (marked “Preview”)</td> --from/to-distribution-spec</code> handles referrers-tag vs. referrers-API mismatches between registries</td></tr>
skopeo copy</code></td> opt-in</td> not supported</td> needs use-sigstore-attachments: true</code> under the default-docker</code> key in registries.d</code>, on both source and destination</td></tr>
Zot registry sync</code></td> syncLegacyCosignTags</code> (default true</code>)</td> only with preserveDigest: true</code></td> without preserveDigest</code>, Zot re-encodes Docker-format images to OCI on sync, which changes the digest and detaches the signature</td></tr>
cosign copy</code></td> yes</td> no</td> deprecated</strong> as of sigstore/cosign#4681</a> (merged 2026-02-04) — the tool itself now points to oras copy -r</code> instead</td></tr>
crane copy</code></td> only incidentally, via --all-tags</code></td> no</td> plain manifest/layer copier, no signature awareness at all</td></tr>
Harbor replication</td> per Harbor’s own docs, yes</td> open gap (goharbor/harbor#23210</a>)</td> works for the legacy scheme; OCI 1.1 referrers replication is not yet reliable</td></tr>
</tbody></table>
regctl</code> is the only tool in this comparison that exposes both signature schemes as distinct,
intentional flags rather than as a side effect of copying “everything.” For a registry pair that
already speaks the OCI 1.1 referrers API end to end, oras cp -r</code> is the other option worth
checking — it’s what the cosign project’s own deprecation notice for cosign copy</code> points to.</p>
Example: mirroring with regctl🔗</a></h2>
Here is an example command to mirror k8s-scale-app-rs</code> itself, signature included, using regctl</code>:</p>
regctl</span> image</span> copy</span> \</span></span>
  -</span>-digest-tags</span> -</span>-referrers</span> \</span></span>
  ghcr.io/git001/k8s-scale-app-rs:v1.0.0</span> \</span></span>
  my-private-registry.example.com/k8s-scale-app-rs:v1.0.0</span></span></code></pre>Sources🔗</a></h2>

sigstore/cosign PR #4681 — “Deprecate cosign copy”</a></li>
sigstore/cosign#4335 — Complete OCI 1.1 Referrers API Support Across All Cosign Commands</a></li>
sigstore/cosign#4564 — cosign verify fails after cosign copy (JFrog Artifactory)</a></li>
podman-container-tools/skopeo#2061 — sigstore signature copying and use-sigstore-attachments</code></a></li>
regctl image copy</code> reference</a></li>
oras cp</code> command reference</a></li>
goharbor/harbor#23210 — OCI 1.1 referrers not replicated</a></li>
Zot registry: mirroring/sync documentation</a></li>
OpenShift Container Platform 4.18 release notes</a></li>
openshift/oc-mirror — signature-verification.md</a></li>
</ul>


What is a (D)DoS - technical
aleks — Sat, 20 Jun 2026 00:00:00 +0000
The technical follow-up to the non-technical (D)DoS overview</a>. Covers Layer 3/4 network floods (SYN, UDP, amplification), BGP hijacking, Layer 7 application DDoS, and operational resilience — all focused on availability.</p>
Originally published at opensourcerers.org</a>; updated with current attack vectors and technologies.</p>


What is a (D)DoS
aleks — Sat, 20 Jun 2026 00:00:00 +0000
(D)DoS attacks are not just a technical problem — they operate at the Business, Social, and Informational level as well. This post covers the non-technical dimensions; the technical follow-up</a> covers Layer 3/4 network floods, BGP hijacking, TLS handshake attacks, Layer 7 application DDoS, and operational resilience.</p>
Originally published at opensourcerers.org</a>; updated with current examples and expanded framing.</p>


(D)DoS and Application Security: The Complete Guide
aleks — Fri, 19 Jun 2026 00:00:00 +0000
This is the index and reading guide for a three-part series on denial-of-service and application
security. The first two parts cover availability</strong> attacks — a service being made unreachable or
unusable — at levels most people don’t associate with the term “DDoS”: the business level (losing
the people who run the service), the social level (manipulating the humans behind it), the
informational level (reputational disruption), and finally the technical level most readers expect
(network floods, BGP hijacking, Layer 7 exhaustion). The third part is a deliberate step sideways,
into application-layer attacks — SQL Injection, Log4Shell, the OWASP Top 10 — that threaten
confidentiality and integrity</strong> instead of availability.</p>


How I work with Claude Code
aleks — Wed, 10 Jun 2026 00:00:00 +0000
Since 2025, I have been using AI tools as part of my daily work. Not as a replacement for
thinking — as a productivity aid. An AI coding agent has become a regular part of how I work on infrastructure, blog posts,
and software projects. Most of what follows likely applies to other agents as well —
Cursor, Copilot, or whatever comes next. I happen to use Claude.</p>
This post is not a tutorial and not a pitch. It is a reflection on what actually works — for me, on my projects —
across months of real use, across 40+ projects, and across months of agent use.</p>


LLM Inference on OVH MKS: Connect IDEs and Web UIs
aleks — Tue, 02 Jun 2026 00:00:00 +0000
The first four parts of this series deployed a vLLM inference endpoint at
https://llm.YOUR_DOMAIN/v1</code>, protected by a Bearer token, running on an OVH RTX5000-28 GPU node.
This part shows how to connect coding assistants, web UIs, and other OpenAI-compatible clients
to that endpoint.</p>


LLM Inference on OVH MKS: Terraform, Ansible, and Deployment
aleks — Tue, 02 Jun 2026 00:00:00 +0000
Part 1</a> covered the architecture and use cases. This post walks through the complete Terraform and Ansible setup and a first deployment.</p>


LLM Inference on OVH MKS: LiteLLM API Gateway
aleks — Tue, 02 Jun 2026 00:00:00 +0000
Parts 1–5 deployed a functional self-hosted LLM endpoint. This part adds LiteLLM</a> — an open-source proxy that exposes a unified OpenAI-compatible API across multiple LLM backends — in front of vLLM. The gateway layer brings per-user API keys, budget enforcement, and automatic fallback to commercial APIs when the local model is unavailable.</p>


LLM Inference on OVH MKS: The Complete Guide
aleks — Tue, 02 Jun 2026 00:00:00 +0000
This is the index and reading guide for a six-part series on self-hosting LLM inference on a
GPU-enabled Kubernetes node pool, using OVH Managed Kubernetes Service (MKS) as the concrete
platform throughout. The series runs end to end: the decision of whether to self-host at all,
provisioning the GPU infrastructure, serving a model behind an OpenAI-compatible API, wiring up
observability and autoscaling, connecting real client tools, and finally putting a multi-user
gateway in front of the whole thing.</p>


LLM Inference on OVH MKS: Introduction
aleks — Tue, 02 Jun 2026 00:00:00 +0000
This post covers the decision context for self-hosting LLM inference on OVH MKS: when it makes sense, what the stack looks like, and what the costs are. Part 2</a> walks through the Terraform and Ansible setup.</p>


LLM Inference on OVH MKS: Prometheus, Grafana, and KEDA
aleks — Tue, 02 Jun 2026 00:00:00 +0000
Part 1</a> covered the architecture and use cases.
Part 2</a> walked through Terraform and Ansible.
Part 3</a> covered models and the OpenAI API.
This part adds observability (Prometheus + Grafana) and scale-to-zero autoscaling via KEDA.</p>


LLM Inference on OVH MKS: Models, AWQ, and OpenAI API
aleks — Tue, 02 Jun 2026 00:00:00 +0000
Part 1</a> covered the architecture and use cases.
Part 2</a> walked through the Terraform and Ansible setup.
This post covers which models fit on the RTX5000-28’s 16 GB GPU VRAM, why AWQ quantization is required for 7B+ models,
and how to use the OpenAI-compatible endpoint from your own code.</p>


SigNoz on OVH MKS: Access Log Reports with Vector and ClickHouse
aleks — Mon, 18 May 2026 00:00:00 +0000
Posts 1</a> and 2</a> of this series set up the SigNoz observability stack on OVH MKS and demonstrated metrics, traces, and Kubernetes pod log collection. This post adds a practical use case: structured Envoy access log collection via Vector, archiving to OVH Object Storage in Combined Log Format, and monthly HTML reports via awffull — accessible at https://reports.<your-domain></code> through the existing Istio gateway.</p>


SigNoz on OVH MKS: The Complete Guide
aleks — Sat, 16 May 2026 00:00:00 +0000
This is the index and reading guide for a three-part series that turns storage-engine theory into a
fully reproducible, sovereign observability stack: SigNoz</a> Community Edition on
OVH Managed Kubernetes Service (MKS), with metrics, distributed traces, and logs all stored in a
single ClickHouse cluster and cold-tiered to OVH Object Storage Infrequent Access. It is an
alternative to hyperscaler-locked observability SaaS, built as a working example repository rather
than a slide deck — clone it, fill in credentials, run Terraform and Ansible. Unlike a stack that
bolts together Prometheus, Jaeger or Tempo, and Loki or Elasticsearch as three separately-operated
databases, SigNoz stores metrics, traces, and logs together in ClickHouse from the start — one
retention policy, one S3 tiering config, one SQL interface, instead of three.</p>


SigNoz on OVH MKS: Infrastructure with Terraform + Ansible
aleks — Sat, 16 May 2026 00:00:00 +0000
The previous two series covered the theory: which storage engine fits 7-year log archiving</a> and what managed cloud services cost</a>. This post turns that analysis into a fully reproducible sovereign observability stack. The goal is not just lower cost, but operational control and EU-hosted observability without hyperscaler lock-in — SigNoz</a> Community Edition on OVH, with metrics, distributed traces, and logs all stored in ClickHouse with S3 cold-tier tiering to OVH Object Storage Infrequent Access.</p>


SigNoz on OVH MKS: Metrics, Traces & Logs with Istio Ambient
aleks — Sat, 16 May 2026 00:00:00 +0000
Part 1</a> set up the infrastructure: OVH MKS, vRack, Istio Ambient Mode, and SigNoz itself via Terraform + Ansible. This post covers what to do after the cluster is running — sending telemetry data, verifying the S3 cold tier is active, and building the first dashboards.</p>


Running pdns_recursor as a root-independent validating resolver
aleks — Mon, 06 Apr 2026 00:00:00 +0000
PowerDNS Recursor</a> is a mature, production-grade recursive DNS resolver. This post documents how to configure it to bootstrap directly from a local root.zone</code> file — so it never needs to reach the root name servers at runtime — with full DNSSEC validation producing the ad</code> flag in responses.</p>


Running a validating DNS recursor from the root zone with Hickory DNS
aleks — Sat, 04 Apr 2026 00:00:00 +0000
Hickory DNS</a> is a Rust-based DNS implementation that covers the full stack: resolver, recursor, authoritative server, and DNSSEC. This post documents how to run it as a full recursive resolver</strong> — starting directly from the root zone, with DNSSEC validation and encrypted upstream transport — based on the changes developed in the recurser-from-root-zone</code></a> branch.</p>


vigil-log-relay: Kubernetes Log Collection Without a DaemonSet
aleks — Sun, 22 Mar 2026 00:00:00 +0000
Every team running workloads on Kubernetes eventually faces the same question:
how do you get logs out of your pods and into your log aggregation stack?
The standard answer is a DaemonSet. It works, but it comes with a cost.
vigil-log-relay</a></strong> is a different answer.</p>


vigil-rs: A Rust Service Supervisor for Containers
aleks — Sat, 21 Mar 2026 00:00:00 +0000
Every container that runs more than one process needs a supervisor. Most reach for
dumb-init</code>, tini</code>, s6-overlay</code>, or supervisord</code>. None of them felt quite right
for what we needed, so we wrote vigil-rs</strong>.</p>
This post walks through what github.com/git001/vigil-rs</a> is, why we built it, and how it works internally.</p>


tls-proxy-tunnel: Transparent TLS Tunnelling Through Corporate HTTP Proxies
aleks — Tue, 02 Jul 2024 00:00:00 +0000
Many enterprise networks sit behind a corporate HTTP CONNECT proxy. Applications
that speak TLS natively — think git</code>, curl</code>, SSH-over-HTTPS, or any custom
binary — often have no built-in proxy support. Configuring every single tool is
tedious, fragile, and sometimes impossible when you don’t control the binary.</p>
tls-proxy-tunnel</code> (tpt</code>) solves this at layer 4: it sits between your
application and the outside world, intercepts the TLS connection, extracts the
Server Name Indication (SNI) from the ClientHello, and tunnels the raw bytes
through your corporate HTTP CONNECT proxy — without ever terminating TLS.</p>


Building a native file upload handler for Caddy v2
aleks — Tue, 01 Mar 2022 00:00:00 +0000
When Caddy v2</a> was released in 2020, it introduced a new concept of handlers that use Go’s native module features.</p>
In 2022 one of our customers needed to upload files, and at that time none of the available web servers could handle this natively without an extra program. So I decided to create a new handler for Caddy v2 — caddyv2-upload</a> was born.</p>
I was not aware of any other tool which can handle file uploads natively in just one binary which can be used in Kubernetes or OpenShift, or I have not searched hard enough 😁. I also wanted to learn go, so I decided to create a new handler for the go based webserver caddyserver</a>.</p>
In May 2022 dufs</a>, a Rust-based server, was created — so that might be another option worth considering. 🤷</p>
Any how I wanted to learn go in the pre AI Area and at that time I looked into the docs of go modules, into the source of caddy servers own handlers and created step by step a new handler.</p>
Luckily there was already podman and buildah, so I was able to create container images to run and test locally.</p>
Building something real turned out to be the most effective way to learn Go. Diving into Caddy’s own handler source code, understanding the module system, and iterating with containers made the concepts stick far better than any tutorial would have.</p>
A minimal Caddyfile configuration looks like this:</p>
{</span></span>
    order upload before file_server</span></span>
}</span></span>
</span>
:2015 {</span></span>
    root .</span></span>
</span>
    file_server browse</span></span>
</span>
    @mypost method POST</span></span>
    upload @mypost {</span></span>
        dest_dir /var/uploads</span></span>
        max_filesize 4MB</span></span>
    }</span></span>
}</span></span></code></pre>
Build with xcaddy</a>:</p>
xcaddy</span> build</span> -</span>-with</span> github.com/git001/caddyv2-upload</span></span></code></pre>
Today caddyv2-upload</a> (v0.20.0) supports file uploads via HTTP multipart form, configurable destination directories, UUID-based subdirectory creation per upload, fixed filenames, pass-through mode to continue to the next Caddy handler after upload, configurable file size limits, an HTTP notification callback after successful uploads, and a /health</code> endpoint. It integrates with Caddy’s variable system and works in Kubernetes and OpenShift environments. Authentication is handled by Caddy’s own security layer rather than the module itself.</p>


How does SNI Routing work in HAProxy
aleks — Fri, 17 May 2019 00:00:00 +0000
As I travel a lot I faced the problem that in some Wi-Fi networks certain ports are blocked for outgoing communication 😱. The solution is to use software that can handle TCP and HTTP via port 443</strong> so that I can use my Nextcloud and my XMPP client on the same port.</p>

Which Tool Mirrors a Cosign-Signed Image into a Private Registry?

What is a (D)DoS - technical

What is a (D)DoS

(D)DoS and Application Security: The Complete Guide

How I work with Claude Code

LLM Inference on OVH MKS: Connect IDEs and Web UIs

LLM Inference on OVH MKS: Terraform, Ansible, and Deployment

LLM Inference on OVH MKS: LiteLLM API Gateway

LLM Inference on OVH MKS: The Complete Guide

LLM Inference on OVH MKS: Introduction

LLM Inference on OVH MKS: Prometheus, Grafana, and KEDA

LLM Inference on OVH MKS: Models, AWQ, and OpenAI API

SigNoz on OVH MKS: Access Log Reports with Vector and ClickHouse

SigNoz on OVH MKS: The Complete Guide

SigNoz on OVH MKS: Infrastructure with Terraform + Ansible

SigNoz on OVH MKS: Metrics, Traces & Logs with Istio Ambient

Running pdns_recursor as a root-independent validating resolver

Running a validating DNS recursor from the root zone with Hickory DNS

vigil-log-relay: Kubernetes Log Collection Without a DaemonSet

vigil-rs: A Rust Service Supervisor for Containers

tls-proxy-tunnel: Transparent TLS Tunnelling Through Corporate HTTP Proxies

Building a native file upload handler for Caddy v2

How does SNI Routing work in HAProxy

Alek's Blog - infrastructure

Sovereign-Cloud-Washing: Five Questions

Who Has Access? Humans, Accounts, AI Agents

Legally vs. Technically Enforced

Can You Leave? Data Portability & Egress

Digital Sovereignty: The Complete Guide

What Does It Cost to Leave — or Arrive?

Who Builds the Platform? Ownership vs. Stack

k8s-scale-app-rs: Scale or Restart a Kubernetes Deployment from a CronJob