DEV Community: Amit Shukla

Self-hosting open source is easy. Running it in production is not.

Amit Shukla — Thu, 10 Sep 2026 19:24:53 +0000

You picked an open source tool on purpose. Maybe it was n8n instead of a per-task automation SaaS, Keycloak instead of paying per active user for auth, Postgres and Grafana and Mattermost instead of three separate subscriptions that each want a seat license. The pitch is good: own your data, no per-seat bill, no vendor deciding your roadmap.

You run docker compose up. It works. You show the team. Everyone is happy.

Then it goes to production, and the actual job starts.

The work that is not in the README

The README gets you a running process. Keeping that process healthy, safe, and recoverable for the next two years is a different list:

Sizing and provisioning. How much CPU, memory, and disk does this actually need under real load, and what happens when it grows.
OS patching. The host needs security updates on a schedule, and someone has to apply them without taking the service down at a bad time.
Application updates. The upstream project ships a release with a security fix. Now you need to update without breaking your config, your database schema, or your integrations, and you need a way back if it goes wrong.
TLS. Certificates that issue and renew automatically, and do not silently expire on a Sunday.
Backups. Not a cron job that writes to the same disk. Off-host, encrypted, with a retention policy, and actually tested by restoring them.
Monitoring and alerts. You want to know the disk is 80 percent full before it is 100 percent full and the database has stopped accepting writes.
Email. Most of these apps need to send mail for invites, resets, and notifications. Getting that delivered instead of dropped into spam is its own project: SPF, DKIM, DMARC, a warmed sending IP or a relay.
Network security. A firewall that exposes only what should be exposed, and some answer for volumetric attacks.
Secrets and log hygiene. Rotating credentials, rotating logs before they eat the disk.
Tracking disclosures. Every app you self-host is now something you have to watch for CVEs, per project, forever.

None of this is hard in isolation. All of it together, across five or six self-hosted apps, is a part time job. And it is usually a part time job that lives in one engineer's head.

The two options most teams settle for

Do it yourself on a VPS. This works. It works right up until the person who set it up is on leave during an incident, or the one undocumented step in the upgrade runbook gets skipped, or a restore is needed for the first time and nobody has ever tested one. The software is free. The operational knowledge is expensive and fragile.

Pay for the vendor's hosted version. Faster to start, but you are often back to per-seat pricing, your data sits on their infrastructure, and you have given up the control that made you choose open source in the first place. For some tools the managed tier costs several times the raw compute.

There is a third option, which is to treat "operating open source software" as a solved, boring layer that you rent.

What a managed layer looks like: Elestio

One option in this space is Elestio. It runs a managed layer on top of open source software that you still own.

You pick an app from a catalog of more than 400+ open source templates. You pick where it runs: a major cloud provider and region of your choice, or your own virtual machines, or your own hardware on premise. It deploys onto a dedicated instance, not a shared multi tenant box.

From there the operational list above is handled for you:

Automated encrypted backups, off host, with retention, and restore that has been tested
Monitoring with alerting on the things that actually page you
Automatic OS patching and application updates, with a rollback path
Managed SMTP so outbound mail is set up and deliverable
TLS certificates that issue and renew on their own
A firewall and DDoS protection in front of the instance
Built in CI/CD if you are deploying your own code alongside
Support that covers the stack, not just the VM

You keep root access. It is your instance and your data. The billing is a flat fee on top of the compute, not per user, so it does not punish you for adding people.

When this makes sense, and when it does not

It makes sense if you are a small or mid sized team without a dedicated platform or SRE function, you want the economics and control of open source, and you would rather your engineers ship product than babysit a Postgres upgrade.

It makes less sense if you already have a mature platform team, infrastructure as code for all of this, tested restores, and an on call rotation. If you have built that muscle, keep using it.

Takeaway

Open source software being free to license does not make it free to operate. Backups, patching, updates, monitoring, mail, and security tracking are the real cost, and they do not show up until you are in production.

The question worth asking is whether operating this software is a competitive advantage for your business. If it is, invest in doing it well. If it is not, and for most teams it is not, hand that layer to something that does it for a living and get back to the work only you can do.

Multi-stage Docker builds: ship the artifact, not the build shop

Amit Shukla — Thu, 10 Sep 2026 19:14:54 +0000

Most Node images I inherit are somewhere north of a gigabyte. The app inside is maybe 40 MB. The other gigabyte is the build shop: compilers, dev dependencies, the npm cache, a full copy of the source, and whatever the base image shipped with.

That gigabyte costs you every day. Slower pulls on every deploy and every autoscale event. More layers for your scanner to chew through. A bigger surface for a CVE to land on. And a longer gap between "push" and "running in production".

Multi-stage builds fix this without touching your application code. Here is how they work and how to get the details right.

What ends up in a single stage image

When you write a normal Dockerfile, every instruction adds a layer, and every layer stays in the final image. A typical Node build looks like this:

FROM node:20
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build
CMD ["node", "dist/server.js"]

The final image now contains:

node:20, which is Debian plus the full Node toolchain, around 1.1 GB before you add anything
every dependency, including the dev ones you only need to compile
the npm cache left behind by npm ci
your entire source tree, not just the compiled output
any build artifacts you generated on the way

You run node dist/server.js. Everything else is dead weight that ships anyway.

The multi-stage pattern

A multi-stage Dockerfile has more than one FROM. Each FROM starts a new stage with its own filesystem. You do the messy work in an early stage, then start a clean final stage and copy in only what you need with COPY --from.

FROM node:20 AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

FROM node:20-slim
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev
COPY --from=build /app/dist ./dist
CMD ["node", "dist/server.js"]

Two things changed:

The first stage is named build with AS build. It installs everything and compiles. None of its layers reach the final image.
The second stage starts from node:20-slim, a much smaller base. It installs production dependencies only, then copies the compiled dist folder out of the build stage.

The compilers, the dev dependencies, and the source tree never make it into the image you ship. Same build, a fraction of the size.

Get these four details right

Name your stages

Use AS <name> on stages you copy from, then reference them in COPY --from=<name>. You can also copy from an external image directly, for example COPY --from=nginx:latest /etc/nginx/nginx.conf ./, which is handy for grabbing a single binary or config file.

Do not copy node_modules across stages

It is tempting to COPY --from=build /app/node_modules ./node_modules and skip a second install. Do not. The build stage has dev dependencies mixed in, and native modules may have compiled against a different base image. Run npm ci --omit=dev in the final stage so you get a clean production tree that matches the runtime.

Order instructions so the cache survives

Docker caches each layer and reuses it until something upstream changes. Copy your lockfiles and install before you copy the rest of the source:

COPY package*.json ./
RUN npm ci
COPY . .

Now a change to your application code invalidates only the COPY . . layer and everything after it. The dependency install, which is the slow part, stays cached. Reverse those lines and every one line code change reinstalls everything.

Go smaller on the final base

node:20-slim drops most of the Debian extras. For a bigger cut, gcr.io/distroless/nodejs20 ships Node and nothing else, no shell, no package manager. It is stricter to debug but the attack surface is tiny. Whatever you pick, add a non-root user:

FROM node:20-slim
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev
COPY --from=build /app/dist ./dist
USER node
CMD ["node", "dist/server.js"]

The same feature, other uses

Multi-stage is not only about size.

One Dockerfile, several targets. Add a test stage and build just that stage in CI with docker build --target test .. Your test image and your production image come from the same file and the same base layers.

FROM node:20 AS build
# ... install and compile ...

FROM build AS test
RUN npm run lint && npm test

FROM node:20-slim AS production
# ... copy artifact ...

Pulling a tool without installing it. Need dockerize or a specific CLI at runtime? Copy the single binary from its published image in a stage instead of running a package manager in your final image.

What this looks like in numbers

On a plain Express and TypeScript service:

Single stage on node:20: about 1.1 GB
Multi-stage with node:20-slim and --omit=dev: about 180 MB
Multi-stage with distroless: about 130 MB

Pull time on a cold node drops from tens of seconds to a few. Your scanner has less to report. And nothing in the image can compile code or run a shell that does not need to.

Takeaway

Build with the full toolchain in an early stage. Start the final stage from the smallest base you can debug, install production dependencies only, and copy in just the artifact. Name your stages, keep your install layer above your source copy, and run as a non-root user. It is a ten line change to your Dockerfile and it pays off on every deploy.