VPN отключился молча: как я потерял доступ к релизу

When Infrastructure Hides Behind the VPN: The Friday Night Lesson

The deadline was Friday evening. The speech-to-text project needed its v1.0.0 release pushed to master, complete with automated build orchestration, package publishing to GitLab Package Registry, and a freshly minted version tag. Standard release procedure, or so I thought—until the entire development infrastructure went radio silent.

My first move was instinctive: SSH into the GitLab server at gitlab.dev.borisovai.tech to check on Gitaly, the service responsible for managing all repository operations on the GitLab backend. The connection hung without response. I tried HTTP next. Nothing. The entire server had vanished from the network as far as I could tell. Panic wasn’t helpful here, but confusion was—the kind that forces you to think systematically about what you’re actually seeing.

Then it clicked. I checked my VPN status. No connection to 10.8.0.x. The OpenVPN tunnel that bridges my machine to the internal infrastructure at 144.91.108.139 had silently disconnected. Our entire GitLab setup lives behind that wall of security, completely invisible without it. I wasn’t dealing with a server failure—I was on the wrong side of the network boundary, and I’d forgotten about it entirely.

This is the quiet frustration of modern infrastructure: security layers that work so seamlessly you stop thinking about them, right up until they remind you they exist. The VPN wasn’t broken. The server wasn’t broken. I’d simply lost connectivity to anything that mattered for my task.

Here’s something interesting about Gitaly itself: it’s not just a repository storage service—it’s a deliberate architectural separation that GitLab uses to isolate filesystem operations from the main application. When Gitaly goes offline, GitLab can’t perform any Git operations at all. It’s like cutting the legs off a runner and asking them to sprint. The design choice exists because managing raw Git operations at scale requires careful resource isolation, and Gitaly handles all the heavy lifting while the GitLab web interface stays focused on its job.

The fix was mechanical once I understood the problem. Reconnect the OpenVPN tunnel, then execute the release sequence: git push origin master to deploy the automation commit, followed by .\venv\Scripts\python.exe scripts/release.py to run the release orchestration script. That script would compile the Python application into a standalone EXE, package it as a ZIP archive, upload it to GitLab Package Registry, and create the version tag—all without human intervention.

VPN restored, Gitaly came back online, and the release shipped on schedule. The lesson here isn’t technical; it’s about remembering the invisible infrastructure that underpins your workflow. Before you blame the server, blame the network. Before you blame the network, check your security tunnel. The most complex problems often have the simplest solutions—if you remember to check the obvious stuff first.

😄 Why did the DevOps engineer break up with the database? Because they had too many issues to commit to.