DevOps

If you still run next build directly on the production server — your server is really suffering. CPU pegged, OOM-kill, 502 errors and long downtimes — this is a classic that needs to end.

In 2026 the industry standard is separate builds:

1. Build a minimal standalone image in the cloud (GitHub Actions).
2. Push it to GHCR (GitHub Container Registry).
3. On the server do only pull + atomic restart.

Chapter 1. The ideal Dockerfile (Multi-stage + Standalone)

The whole secret to a small and fast image is the standalone mode. Next.js itself figures out which files and parts of node_modules are actually needed to run the server, and copies only them.

When a project moves beyond local development and starts using CI/CD, a fundamental question arises: how to securely pass configuration parameters into build and deployment pipelines. This concerns not only database passwords, but also container registry tokens, SSH keys, JWT signing keys, message queue connection strings, and any other parameters that must not be stored in plain text.

Sensitive data ending up in a Git repository is not just bad practice. The commit history is kept forever. Even if a secret is removed in a later commit, it has already become part of the history and can be retrieved via git log, git show or when cloning a fork. In a corporate environment this becomes a real risk during audits, team expansion, or if repository access is leaked.

There were several issues concerning both the technical side and overall understanding. Mikhail responded quickly to the request, helped sort things out and resolved the technical problems and helped clarify understanding, for which a special thank you. I am satisfied with the result.

Answer: Thank you for the feedback! Glad to help!

Everything was done quickly and efficiently. I recommend.

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.

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.

Over the last ten years the web application deployment industry has evolved from FTP scripts and rsync to highly complex orchestration systems. Today developers and small teams increasingly face a difficult choice:

• either pay a significant premium for the convenience of PaaS platforms (Heroku, Render, Fly.io),
• or dive into the cognitive and operational complexity of Kubernetes.

Kamal offers a third way: the convenience of modern cloud services — on your own server.