DevOps

When Docker first appeared, it was loved for the slogan: “Build once, run anywhere”. Developers stopped hearing the phrase “it works on my machine, but not on the server.” But along with convenience came a new threat.

A container is not just your application. It’s a whole mini-operating system (OS) with its own libraries, utilities, and system calls. And if you don’t look after that OS, you leave hackers with a huge door wide open.

Imagine you are building a house. You designed the walls yourself, checked every brick, and made sure you didn’t leave the keys in the lock. But what if the concrete you bought from a third-party supplier starts crumbling over time? Or the finished window frames you installed have hidden defects?

In modern development the situation is exactly the same. The average application today is 80–90% made up of Open Source libraries. You write only a small portion of the code (the tip of the iceberg) that orchestrates a huge mass of someone else’s code hidden “under the water”.

Have you ever wondered how experienced programmers find bugs in someone else’s code just by looking at it? They look for patterns. They know that if user data goes straight into an SQL query — that’s bad. If a password is compared with a plain == instead of a secure function — that’s a risk.

But a person can’t review 100,000 lines of code without missing something. This is where SAST (Static Application Security Testing) comes in.

Imagine this scenario: you’ve been working on a cool project all night. By 4 a.m. everything is ready, you do a final git push and go to sleep with a clear conscience. In the morning you find your AWS balance is zero and a miner is running on your servers. What happened? It turns out you left a line in one of the files: AWS_ACCESS_KEY_ID = "AKIA...".

This is a classic mistake thousands of developers have made. In this article we’ll look at why “just deleting the password” won’t help and how to set up automatic protection that will physically prevent you from making the mistake.

Write a Dockerfile simply: FROM node, COPY ., CMD run. It works, and for local tests this is often enough. But when such an image reaches CI/CD or, God forbid, production, problems begin: builds take forever, the image weighs gigabytes, and the security team grabs their heads.

The difference between “it works” and “it works correctly” is huge. Let’s go through four levels of optimization that separate a hobbyist hack from a reliable engineering solution.

OpenVPN is a reliable and time-tested VPN protocol that allows organizing secure remote access to a local network. MikroTik RouterOS supports OpenVPN in server mode starting from version 6.x (TCP), and from version 7+ — also UDP, but with a number of architectural limitations:

• mandatory authentication by username/password even when using certificates;
• limited list of ciphers and algorithms;
• absence of some features of “classic” OpenVPN.

Despite this, OpenVPN on MikroTik remains a popular solution — especially in scenarios where clients do not support WireGuard or compatibility with legacy systems is required.

If you do self-hosting, run a home lab, or manage a small VPS, you’re probably familiar with Portainer. It’s the de-facto standard: a powerful, all-encompassing “Swiss Army knife” for Docker.

But let’s be honest: sometimes the Swiss Army knife is too heavy when you just need to peel an apple.

Recently I discovered Dockge — a tool from the same developer as the popular Uptime Kuma. It made me completely rethink how I manage containers. In this article I’ll explain why Dockge can be the perfect replacement for Portainer in many scenarios.

When working on real projects (CDN change, migration, refactor) you often need to bulk-replace one URL with another.

At first glance the task seems trivial: sed -i 's|old|new|g' **/* — and done.

In reality that approach is Russian roulette.

A careless replacement leads to:

• 💀 Corruption of binary files (images, pdf, archives);
• 📉 Garbage in git history (binaries marked as changed);
• 🚫 Inability to cleanly roll back if a backup wasn’t made.

In this note we’ll cover a production-grade algorithm: change only text, don’t touch binaries, make a targeted backup.

Jitsi Meet works out of the box very well for video conferencing. The Jitsi Meet + Jibri bundle allows you to record meetings — and many installations stop there.

But as soon as Jitsi is used not occasionally, but as part of a working process, questions arise very quickly:

• Where should recordings be stored centrally?
• How can links be automatically published for the team?
• How can we get rid of heavy MP4 files and move to streaming playback?
• How can recordings be served over HTTPS without exposing the directory structure?
• How can all of this be done automatically, without manual administrator involvement?

Below is a full production pipeline with code: from Jibri finalizing a recording to publishing in Notion and asynchronous MP4→HLS transcoding with delivery via Caddy.

Mikrotik routers are rightly valued by system administrators for their incredible flexibility.
A unique feature of this hardware is that a budget home hAP lite and a powerful enterprise router costing thousands of dollars run the same operating system — RouterOS.

That means once you learn to configure one device, you can manage any equipment from the brand.
In this article we’ll go over the fundamental steps to set up a Mikrotik from scratch to a fully working state.