Our PostgreSQL backups looked healthy. The scheduled jobs completed, the files were there, and monitoring showed no errors. Then I tried restoring the database on a clean server. That simple test exposed problems our backup monitoring had never noticed.
A green build that produces a 15-byte index.html is a strange thing to look at. The file contains exactly this:
In this article, I'll show how I updated NVIDIA drivers manually and automated the process using a DaemonSet and NVIDIA GPU Operator.
I'll also explain the problems we faced with pre-installed drivers and how I solved them.
This article explains how to build an ML platform on top of Kubernetes for data analysts. It covers JupyterHub as the main entry point, S3-compatible object storage for datasets, CSI-based bucket mounting, and an automated infrastructure that simplifies data access, experimentation, and machine learning workflows.
A Linux gateway began dropping new connections even though CPU usage was low, memory looked healthy, disks were almost idle, and the application itself continued responding normally. The same failure was reproduced twice in a small lab and investigated using two completely different approaches. The first run relied on tools that would have been familiar to a Linux sysadmin in 2008: top, vmstat, dmesg, proc, sysctl, netstat, and tcpdump. The second run started with Prometheus, Grafana, historical metrics, and modern observability. Both approaches eventually reached the same kernel-level problem, but the path to the answer was very different.
Self-hosted Sentry means 65 containers, 16-32 GB of RAM, and a dedicated engineer just to keep it alive. All that - to catch stack traces. We dig into why the industry treats this as normal, compare the alternatives (GlitchTip, BugSink, Hawk), and take a look at Metric - a Sentry-compatible monitoring platform written in Rust that runs on 1 GB of RAM and two containers. Migration is a single-line DSN change.
The idea appeared after a normal working evening went slightly wrong.
I opened a repository, started a build, and noticed that nearly every useful action required a connection to somebody else’s server. The source code was hosted remotely. The CI runner was remote. Package metadata came from remote registries. Test files were downloaded from object storage. API collections were synchronized through a cloud account. Documentation lived in another browser tab. Even code completion waited for a remote model.
My laptop was powerful enough to compile the project, run several databases, and heat the room better than the radiator. Still, it behaved more like a terminal connected to a collection of external services.
So I made a simple rule for one month:
The main development workflow had to remain usable with the network disconnected.
I did not try to recreate the entire Internet in Docker. Public package registries, operating system updates, and communication tools were still allowed during planned synchronization periods. But coding, commits, builds, tests, documentation, API experiments, and basic code review had to work locally.
The first assumption was that this would mostly be a Docker Compose exercise.
It was not.
The containers were the easy part. The difficult part was discovering all the invisible contracts hidden inside a normal cloud-based workflow.
A lot of security conversations still start with a familiar question:
EV charging platforms look familiar at first: APIs, cloud infrastructure, mobile apps, CI/CD, Kubernetes, telemetry, admin tools, and billing-adjacent logic. But the risk model is different. A weakness in authorization, release governance, device identity, or observability can affect not only data, but also charging sessions, stations, firmware, fleet operations, and recovery workflows.
This article explains how to approach EVSE as a Product Security problem, not just an AppSec problem.
How we transformed stressful manual releases into a dependable, one-click process using GitOps and automation. 50+ modules, auditors and regulators—in a single template that scaled across more than 30 services. No magic, an engineering discipline.
From hype to strategy: how EXANTE redefined Cloud Native after painful Kubernetes mistakes, lessons learned, and building a more resilient infrastructure
Ashamed to admit, I still use Swarm in 2025. It's easy to explain, quick to set up, and simple to use. It's a starting point in the world of containers when full-blown Kubernetes is overkill. But Docker's evolution hasn't been the most straightforward. Over time, it began to lack a minimal dynamic proxy for Swarm - one that you run once, which configures traffic routing to microservices automatically - and forget about it. That's how Millau was born - an ingress-proxy and load balancer based on labels. It currently powers its own website and a few other projects.
Learning Shopify has been on my bucket list for a few years now. Plenty of people in my circle — friends, colleagues, and fellow devs — are all somehow involved with Shopify in one way or the other. Earlier this year, I finally had some breathing room between projects, so I figured it was the perfect time to give Shopify a proper look.
I started exploring the platform by setting up a dev store, poking around the admin, and skimming through the API manual. While this was a quick and easy start, it didn’t give me a deeper understanding of the platform. Plus, clicking my way through the UI felt repetitive and tedious.
That got me thinking: is there a more efficient, developer-centric way to manage a store? Something that I could run in a terminal, plug into a CI/CD pipeline, or script my way out of those mundane tasks.
You may have already read in the news that on the eve of Cosmonautics Day, a new stable release of Angie 1.9.0 was released, an nginx fork that continues to be developed by the team of former nginx developers. Approximately every quarter, we try to release new stable versions and delight users with numerous improvements. This release is no exception, but it's one thing to read a dry changelog and quite another to get to know the functionality in more detail, to learn how and in which cases it can be applied.
The list of innovations that we will discuss in more detail:
— Saving shared memory zones with cache index to disk;
— Persistent switching to a backup group of proxied servers;
— 0-RTT in the stream module;
— New busy status for proxied servers in the built-in statistics API;
— Improvements to the ACME module, which allows automatic obtaining of Let's Encrypt TLS certificates and others;
— Caching TLS certificates when using variables.
Imagine a familiar situation: it’s Monday morning, tasks are piling up, and you need to quickly spin up a new service using Postgres Pro. Or maybe you’ve just upgraded your database server over the weekend — added more CPUs, more RAM.
Here’s how to get your database tuned and ready to make the most of the new hardware and workload, without wasting time.
It’s Never Too Late: My Start into DevOps
Summary
Learn about the challenges, growth, and lessons gained — from juggling work, studies, and a pet project to achieving a dream.
In today's interconnected development world, secure authentication is not just a luxury—it's a necessity. Whether you're a seasoned DevOps engineer or a junior developer just starting your journey, understanding SSH key pairs is crucial for your daily workflow. They're the unsung heroes that keep our git pushes secure, our server access protected, and our deployments safe from prying eyes.
But let's be honest: SSH keys canbe confusing. With terms like “public key infrastructure,” “cryptographic algorithms,” and “key fingerprints” floating around, it's easy to feel overwhelmed. This guide aims to demystify SSH key pairs, breaking down complex concepts into digestible pieces that will help you make informed decisions about your security setup.
Kata Containers is actually now the main way to run containers in an isolated virtual machine for greater security. I tell you how to install them for use with Containerd and Docker while still being able to switch between release versions.
Secret Management and Why It’s Important
Hi! My name is Evgeny, and I work as a Lead DevOps at Exante. In this article, I will discuss the practical experience of setting up a high-availability HashiCorp Vault with a GCP storage backend and auto unseal in Kubernetes (K8s).
Our infrastructure used to consist of thousands of virtual and physical machines hosting our legacy services. Configuration files, including plain-text secrets, were distributed across these machines, both manually and with the help of Chef.
We decided to change the company’s strategy for several reasons: to accelerate code delivery processes, ensure continuous delivery, securely store secrets, and speed up the deployment of new applications and environments.
We decided to transition our product to a cloud-native model, which required us to change our approach to development and infrastructure. This involved refactoring our legacy services, adopting a microservices architecture, deploying services in cloud-based Kubernetes (K8s), and utilizing managed resources like Redis and PostgreSQL.
In our situation, everything needed to change—from applications and infrastructure to how we distribute configs and secrets. We chose Google as our cloud provider and HashiCorp Vault for secret storage. We've since made significant progress on this journey.
Why HashiCorp Vault?
There were several reasons:
A story about evolving our CI process for a monolithic Python repo with tests, challenges faced, and solutions. Discussing Docker, linters, Allure TestOps, and more.
