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 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.

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.

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.

The experience of working together left an extremely positive impression, above all because of the professionalism and the approach to solving the issues that arose.

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

Jitsi Meet is an open videoconferencing platform that easily integrates with Active Directory (AD). Such integration allows using corporate accounts for login, simplifying administration and improving security. In this guide we’ll go through how to connect Jitsi Meet (in Docker) to AD based on Windows Server 2016, and show proven debugging methods that help avoid common errors.

Important: using LDAP without encryption is insecure. For testing this is acceptable, but in production you must use LDAPS (port 636) with valid certificates.

Read more

How to run Jitsi Meet (Docker) behind an Nginx Reverse Proxy

In the previous article we deployed a basic Jitsi Meet server using Docker.
This is a great way to quickly start video conferencing, but in production a Jitsi server often needs to run on the same host where other web applications are already running.
To keep everything peaceful, you should hide Jitsi behind an Nginx reverse proxy.
Nginx will take care of SSL, ports 80/443 and will proxy requests to the Jitsi containers running on internal ports.

Local Telegram Bot API allows developers to run their own API server, providing significant advantages for handling large files, performance, and configuration flexibility. However, to understand the need for a local server, it’s important to consider the limitations of the standard Telegram Bot API that works via an HTTPS interface. In this article we’ll review the benefits of the Local Bot API, the limitations of the standard approach, and steps to set up a local server via Docker, including registering a bot to use with it.

Task

🚀 Create your own fast and reliable proxy, register it in Telegram to track statistics, and optionally make it public.

Solution Choice: Docker + Official MTProto Image

• Why Docker? Docker allows you to run the proxy in an isolated container without installing unnecessary dependencies on the server. It’s clean, secure, and incredibly fast. The docker-compose.yml file describes the entire configuration in one place, making the launch and management process trivial.

  Read more