Alek's Blog - ovh

Who Has Access? Humans, Accounts, AI Agents

aleks — Thu, 09 Jul 2026 00:00:00 +0000

Part 1</a> split the technology-supply-chain question into two halves: what the platform is built on, and who — or what — actually has access to it. Part 2</a> answered the first half. This post answers the second, using systems already built and operated for this blog rather than new research — human access, service-account access, and (increasingly relevant) AI-agent access, all checked against the same bar: is it documented, is it audited, and is it technically enforced or just expected to be followed.

Can You Leave? Data Portability & Egress

aleks — Thu, 09 Jul 2026 00:00:00 +0000

Part 1</a> deliberately kept Question 4 — can you leave — at the general level. This post is the deep-dive: concrete data-export formats, API and query-language openness, and egress pricing already documented for AWS, GCP, Azure, and OVH, plus new findings on how the five sovereignty offerings from Part 2</a> actually hold up on exit.

What Does It Cost to Leave — or Arrive?

aleks — Thu, 09 Jul 2026 00:00:00 +0000

Part 1</a> deliberately kept Question 5 at the general level too: on-prem is largely sovereign, but “engineering time re-architecting for a new platform’s primitives, process changes… and a skills gap no one accounted for” apply whichever direction you’re moving. This post is that deep-dive — the last of the five, using examples already built and published rather than new claims about any provider.

Who Builds the Platform? Ownership vs. Stack

aleks — Thu, 09 Jul 2026 00:00:00 +0000

Part 1</a> raised the technology-supply-chain question with one case: Open Telekom Cloud, legally owned by Deutsche Telekom, running on a Huawei-licensed platform. Five more prominent, more recent cases turn out to follow the same pattern — checked here against primary sources, not just repeated from secondary coverage — alongside three providers where ownership and technology stack come closer to aligning, each with its own gaps left intact rather than smoothed over.

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.


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>


AWS vs. GCP vs. Azure vs. OVHcloud: The Complete Guide to Managed Log Archiving
aleks — Thu, 14 May 2026 00:00:00 +0000
This is the index and reading guide for a six-part series comparing managed log archiving
on AWS, GCP, Azure, and OVHcloud for retention periods of seven years or more. It is
written for teams that have to choose between a hyperscaler’s managed log service and a
self-hosted alternative on OVH, and who need the comparison grounded in real prices, real
API behaviour, and real operational constraints rather than marketing copy. Each part
stands on its own; together they walk the full lifecycle of a long-term log archive — from
what it costs, through how it is built and secured, to how it is run and audited years
after the first log lands.</p>


AWS vs. GCP vs. Azure vs. OVHcloud: Log Archiving Operations
aleks — Thu, 14 May 2026 00:00:00 +0000
This post covers the operational dimension of the managed log archiving comparison</a>:
how each provider integrates with Kubernetes, what ingest pipeline options exist, how
backup and disaster recovery work, and how you observe the log pipeline itself.</p>

Full guide:</strong> AWS vs. GCP vs. Azure vs. OVHcloud: The Complete Guide to Managed Log Archiving</a></li>
Part 1 — Overview & Cost:</a> Services, storage model, 7-year cost comparison</li>
Part 2 — Pre-Flight, Flexibility & Auditor Export:</a> Pre-flight checklist, retroactive flexibility, auditor export</li>
Part 3 — Operations — this post:</strong> Kubernetes integration, ingest pipeline, backup & DR, observability</li>
Part 4 — Security & Compliance:</a> IAM/RBAC, encryption, WORM, GDPR, compliance certificates</li>
Part 5 — Query, Dashboards & Recommendations:</a> Query interfaces, dashboards, alerting, cold-tier behaviour, when to use which</li>
Part 6 — Production Checklist, Guardrails & Runbooks:</a> Loss detection, privacy, schema, cost guardrails, runbooks, fire drills</li>
</ul>
Self-hosted alternative: Elasticsearch vs. OpenSearch vs. Loki vs. Quickwit vs. ClickHouse — Part 2 (Operations)</a></em></p>


Log Archiving Pre-Flight & Auditor Export: AWS / GCP / Azure / OVHcloud
aleks — Thu, 14 May 2026 00:00:00 +0000
This post continues the managed log archiving series with three operational questions that
rarely appear in provider documentation: what must be done before writing the first log,
what cannot be changed retroactively, and how to export logs to an external auditor in
a tamper-evident way.</p>

Full guide:</strong> AWS vs. GCP vs. Azure vs. OVHcloud: The Complete Guide to Managed Log Archiving</a></li>
Part 1 — Overview & Cost:</a> Services, storage model, 7-year cost comparison</li>
Part 2 — Pre-Flight, Flexibility & Auditor Export — this post</strong></li>
Part 3 — Operations:</a> Kubernetes integration, ingest pipeline, backup & DR</li>
Part 4 — Security & Compliance:</a> IAM/RBAC, encryption, WORM, GDPR, compliance certificates</li>
Part 5 — Query, Dashboards & Recommendations:</a> Query interfaces, dashboards, alerting, cold-tier behaviour</li>
Part 6 — Production Checklist, Guardrails & Runbooks:</a> Loss detection, privacy, schema, cost guardrails, runbooks, fire drills</li>
</ul>


7-Year Log Archiving in Production: Checklist, Guardrails & Runbooks
aleks — Thu, 14 May 2026 00:00:00 +0000
Choosing the provider and storage tier is only half of the work. A seven-year log archive
is a production system: it must prove that logs are complete, protect personal data, keep
query costs bounded, survive access-key and restore failures, and give auditors repeatable
evidence without turning every audit into an incident.</p>
This final part turns the provider comparison into an operating checklist.</p>

Full guide:</strong> AWS vs. GCP vs. Azure vs. OVHcloud: The Complete Guide to Managed Log Archiving</a></li>
Part 1 — Overview & Cost:</a> Services, storage model, 7-year cost comparison</li>
Part 2 — Pre-Flight, Flexibility & Auditor Export:</a> Pre-flight checklist, retroactive flexibility, auditor export</li>
Part 3 — Operations:</a> Kubernetes integration, ingest pipeline, backup & DR</li>
Part 4 — Security & Compliance:</a> IAM/RBAC, encryption, WORM, GDPR, compliance certificates</li>
Part 5 — Query, Dashboards & Recommendations:</a> Query interfaces, dashboards, alerting, cold-tier behaviour, when to use which</li>
Part 6 — Production Checklist, Guardrails & Runbooks — this post</strong></li>
</ul>


Log Archiving Security & Compliance: AWS / GCP / Azure / OVHcloud
aleks — Thu, 14 May 2026 00:00:00 +0000
This post covers the security and compliance dimension of the
managed log archiving comparison</a>:
encryption, access control, immutability for regulatory retention, GDPR, and compliance
certifications relevant for EU/DACH environments.</p>

Full guide:</strong> AWS vs. GCP vs. Azure vs. OVHcloud: The Complete Guide to Managed Log Archiving</a></li>
Part 1 — Overview & Cost:</a> Services, storage model, 7-year cost comparison</li>
Part 2 — Pre-Flight, Flexibility & Auditor Export:</a> Pre-flight checklist, retroactive flexibility, auditor export</li>
Part 3 — Operations:</a> Kubernetes integration, ingest pipeline, backup & DR</li>
Part 4 — Security & Compliance — this post:</strong> IAM/RBAC, encryption, WORM, GDPR, compliance certificates</li>
Part 5 — Query, Dashboards & Recommendations:</a> Query interfaces, dashboards, alerting, cold-tier behaviour, when to use which</li>
Part 6 — Production Checklist, Guardrails & Runbooks:</a> Loss detection, privacy, schema, cost guardrails, runbooks, fire drills</li>
</ul>
Self-hosted alternative: Elasticsearch vs. OpenSearch vs. Loki vs. Quickwit vs. ClickHouse — Part 3 (Security)</a></em></p>


Log Archiving Query & Recommendations: AWS / GCP / Azure / OVHcloud
aleks — Thu, 14 May 2026 00:00:00 +0000
This post covers query interfaces, dashboard building, alerting, and cold-tier query
behaviour for the managed log archiving comparison</a>,
and closes with concrete recommendations for each scenario.</p>

Full guide:</strong> AWS vs. GCP vs. Azure vs. OVHcloud: The Complete Guide to Managed Log Archiving</a></li>
Part 1 — Overview & Cost:</a> Services, storage model, 7-year cost comparison</li>
Part 2 — Pre-Flight, Flexibility & Auditor Export:</a> Pre-flight checklist, retroactive flexibility, auditor export</li>
Part 3 — Operations:</a> Kubernetes integration, ingest pipeline, backup & DR</li>
Part 4 — Security & Compliance:</a> IAM/RBAC, encryption, WORM, GDPR, compliance certificates</li>
Part 5 — Query, Dashboards & Recommendations — this post</strong></li>
Part 6 — Production Checklist, Guardrails & Runbooks:</a> Loss detection, privacy, schema, cost guardrails, runbooks, fire drills</li>
</ul>
Self-hosted alternative: Elasticsearch vs. OpenSearch vs. Loki vs. Quickwit vs. ClickHouse — Part 4 (UX)</a></em></p>


AWS vs. GCP vs. Azure vs. OVHcloud: Managed Log Archiving for 7+ Years
aleks — Thu, 14 May 2026 00:00:00 +0000
Long-term log archiving at scale is an expensive problem. Cloud providers offer a wide
range of managed services for ingesting, storing, and querying logs — and the cost
differences between them are dramatic. This series covers AWS, GCP, Azure, and OVH</strong>
along the axes that matter for 7-year archival: services available, storage model, ingest
cost, 7-year total cost at 100 GB/day, Kubernetes integration, security, and query
interfaces.</p>

Full guide:</strong> AWS vs. GCP vs. Azure vs. OVHcloud: The Complete Guide to Managed Log Archiving</a></li>
Part 1 — this post:</strong> Services overview, storage model, and 7-year cost comparison</li>
Part 2 — Pre-Flight, Flexibility & Auditor Export:</a> Pre-flight checklist, retroactive flexibility, auditor export</li>
Part 3 — Operations:</a> Onboarding, Kubernetes integration, ingest pipeline, backup & DR</li>
Part 4 — Security & Compliance:</a> IAM/RBAC, encryption, WORM, GDPR, compliance certificates</li>
Part 5 — Query, Dashboards & Recommendations:</a> Query interfaces, dashboards, alerting, cold-tier behaviour, when to use which</li>
Part 6 — Production Checklist, Guardrails & Runbooks:</a> Loss detection, privacy, schema, cost guardrails, runbooks, fire drills</li>
</ul>
Self-hosted alternative: Elasticsearch vs. OpenSearch vs. Loki vs. Quickwit vs. ClickHouse</a> — tiering, compression, resource consumption, SaaS options.</em></p>

Retaining logs for seven or more years is a very different problem than storing the last
30 days of operational logs. Ingest cost per GB, the ability to query old data without
restoring from tape, and long-term pricing predictability dominate over query latency.
Each of the four providers covered here has a fundamentally different answer to this
problem — and for at least one of them, the honest answer is “our managed offerings are
not designed for this; run it yourself instead.”</p>


ClickHouse Use Case: Vector, Istio, nginx, Java on OVH MKS
aleks — Thu, 14 May 2026 00:00:00 +0000
The first four parts of this series compared Elasticsearch, OpenSearch, Loki, Quickwit, and
ClickHouse across storage models, operations, security, and UX. This part shows what a
concrete production setup looks like when the decision has been made: ClickHouse</strong> as the
log store, Vector</strong> as the ingestion agent, running on OVH Managed Kubernetes Service
(MKS)</strong> with OVH Object Storage</strong> as the cold tier.</p>
This is Part 5 of a five-part series:</p>

Full guide:</strong> Elasticsearch vs. OpenSearch vs. Loki vs. Quickwit vs. ClickHouse: The Complete Guide</a></li>
Part 1</a> — storage models, compression, resource consumption, and SaaS options</li>
Part 2</a> — cluster setup, Kubernetes operations, backup and disaster recovery</li>
Part 3</a> — encryption, RBAC, and WORM compliance</li>
Part 4</a> — UI layers, dashboards, alerting, and cold-tier query behaviour</li>
Part 5 — this post</li>
</ul>