Docker: Alpine vs Debian-slim — stop picking the wrong base image

The rule of thumb (and when to break it)

If your service depends on native libraries, prebuilt binaries, vendor agents, or anything you didn’t compile yourself: start with Debian-slim.
You get glibc, predictable packaging, and fewer weird edge cases. You also get better “it’s 3 AM and I need to see what’s inside” ergonomics.

If you ship a single static binary (Go with CGO_ENABLED=0, Rust with musl, or a carefully controlled build) and you know exactly what you need:
Alpine can be great. It’s also good for tiny utility images where you want BusyBox simplicity and you control every dependency.

If you’re selecting a base image primarily because the compressed size number looks nice on a slide deck, stop. Your base image is an operations choice:
libc, resolver behavior, TLS stack, package manager, debugging surface area, and patch cadence. Size matters, but it’s usually not the thing that wakes you up.

Joke #1: Picking Alpine because it’s smaller is like buying a motorcycle because it fits in your kitchen. Technically true, emotionally suspicious.

A simple decision tree

• Need glibc compatibility (most prebuilt Linux software assumes it): choose Debian-slim.
• Need to compile Python wheels, Node native modules, or use vendor-provided binaries: choose Debian-slim.
• Shipping a single static binary, no shell scripts, no runtime compilation: Alpine is viable.
• Need fast incident debugging inside the container: Debian-slim (or add a dedicated debug image).
• Need the smallest possible final image: use multi-stage builds; consider distroless. Don’t use Alpine as a band-aid.

Facts & context you can use in an argument

These aren’t trivia. They’re the “why is this happening” background that turns base image debates from vibes into engineering.

1. Alpine uses musl libc, not glibc. Many binaries and subtle libc behaviors differ (locale, DNS, threading edge cases).
2. Alpine’s userland is BusyBox-heavy. Common tools exist, but flags and behavior can differ from GNU coreutils.
3. Debian-slim is still Debian: glibc, apt/dpkg, and the ecosystem most Linux software targets by default.
4. “Slim” is about removing docs/locales and some packages, not changing the fundamental ABI expectations of Linux binaries.
5. musl’s DNS resolver behavior is different from glibc’s, and that difference has shown up in production under load or misconfigured resolv.conf.
6. Many language ecosystems distribute glibc-targeted wheels/binaries (Python wheels, Node prebuilt modules, vendor agents). musl often forces source builds.
7. Static linking isn’t a free lunch. It can reduce runtime dependencies but can complicate patching (you patch by rebuilding the app, not the base).
8. Container security scanners count packages. Debian images can show “more CVEs” simply because they contain more packages to match against databases.
9. Alpine historically marketed minimalism and security, but security is about updates, supply chain controls, and runtime posture—not just fewer files.

The real tradeoffs: libc, packages, debugging, security, performance

1) libc compatibility: musl vs glibc is the whole ball game

Alpine’s musl is standards-focused and lean. glibc is… glibc: huge compatibility surface, decades of “this weird thing must keep working because
someone shipped it in 2009.” In container land, compatibility usually wins.

Failure mode: you docker run something that worked on Ubuntu, and it dies on Alpine with a linker error. Or it runs, but has strange
behavior under concurrency, DNS, or locale handling. Your incident ticket will read “random timeouts” or “only fails in prod,” which is always fun.

If you’re deploying third-party binaries (database clients, observability agents, PDF renderers, media tooling), assume glibc until proven otherwise.
Alpine can still work, but you will pay the “investigation tax.”

2) Package ecosystem: apk vs apt isn’t just syntax

Alpine’s apk is fast and straightforward. Debian’s apt is heavyweight but massively compatible. The bigger difference is
what packages exist, how often you need to compile from source, and what defaults are baked in (cert bundles, locales, timezones).

If your Dockerfile includes “build dependencies” (compilers, headers) and you’re trying to keep the runtime image small, you should be doing a
multi-stage build anyway. The package manager becomes a build-time tool, not a lifestyle.

3) Debugging: minimal images are great until you need to debug

In production, you need at least a plan for: “How do I see DNS, routes, TLS chains, and process state?” Debian-slim tends to be friendlier here.
Alpine often forces you to install things mid-incident, which is a great way to discover you blocked outbound egress for good reasons.

There are grown-up ways to do debugging (ephemeral debug containers, sidecars, debug tags). But if you don’t have them, don’t pick a base image
that makes you blind.

4) Security: fewer packages can mean fewer alerts, not fewer risk

Alpine’s smaller footprint often yields fewer scanner findings. That’s not the same as being safer. Vulnerability scanners are package database
matching engines with varying quality, not truth machines.

The operational security question is: can you patch quickly, rebuild deterministically, and ship? Debian’s stable cadence and large ecosystem help.
Alpine’s cadence is also fine, but you need to track it. Either way, you need image rebuild automation, not hope.

5) Performance: sometimes Alpine is slower, sometimes faster, mostly it’s complicated

People love to claim Alpine is “faster” because it’s smaller. Startup time is rarely dominated by a few extra megabytes of filesystem layers;
it’s usually about language runtime initialization, JIT warmup, DNS latency, cold caches, and downstream dependencies.

The performance trap is source builds. On Alpine, you may compile dependencies that would otherwise install as prebuilt wheels/binaries on Debian.
That can make CI slower, builds less repeatable, and occasionally produce different code paths than you tested elsewhere.

6) The reliability framing

I care about two things: can we ship changes quickly, and can we debug when it breaks? That’s it. A smaller base image is nice, but it’s not a
reliability strategy.

Quote (paraphrased idea): Gene Kim often emphasizes that improving reliability comes from shortening feedback loops and making work visible—not from heroic debugging.

Runtime-specific guidance (Go, Java, Node, Python, Rust, Nginx)

Go

If you can build a truly static binary (CGO_ENABLED=0) and you don’t need libc-dependent features, Alpine is fine. You can even go
smaller than Alpine by using scratch or distroless for the runtime image, with a debug image available when needed.

If you use cgo (database drivers, image processing, system integrations), glibc compatibility becomes relevant. Debian-slim is usually the safer default.

Java / JVM

Pick a base image that matches your JDK/JRE distribution expectations. Many JVM distributions assume glibc and standard tooling. Alpine-based JVM
images exist, but you need to be deliberate about CA certs, fonts (yes, fonts), and DNS behavior.

Node.js

Node projects with native modules (node-gyp, bcrypt, sharp, grpc, canvas) are where Alpine pain goes to thrive. You’ll either compile
modules from source (hello build toolchain) or fight prebuilt artifacts that target glibc. Debian-slim avoids most of this.

Python

Python on Alpine often means “build from source” for anything with native dependencies (cryptography, lxml, numpy, pandas). That’s not always bad,
but it’s operationally expensive. Debian-slim tends to get prebuilt manylinux wheels that “just work.”

Rust

Rust can target musl and produce static-ish binaries. That’s a real win for minimal runtime images. Just make sure you understand how you’ll patch
dependencies: you patch by rebuilding the binary, not by apt upgrading a libc.

Nginx / Envoy / HAProxy

For standard web proxying, both are fine. The choice usually comes down to the module ecosystem and your debugging habits.
If you want familiar tooling and predictable modules, Debian-slim is comfortable. If you want a smaller surface and you’re confident in your
build pipeline, Alpine can work.

Three corporate-world mini-stories

Mini-story #1: The incident caused by a wrong assumption

A team migrated a set of internal APIs from “whatever base image we had” to Alpine to cut image size and speed up deployments. Nothing exotic:
Node.js service, talks to Postgres, calls a handful of partner APIs over HTTPS, ships logs. CI was green, staging looked fine.

Two weeks later, production started showing sporadic timeouts on outbound HTTPS calls. Not all calls. Not all regions. And of course not in staging.
Dashboards showed spikes in request latency, then a cascade of retries, then the partner rate-limiting them. Classic reliability spiral: retries
turn a small problem into a loud one.

The wrong assumption was “DNS is DNS.” The container’s resolver behavior differed under the specific resolv.conf setup and the way the cluster
injected search domains. Under load, those extra search attempts and different caching behavior amplified latency. The service wasn’t “broken,”
it was consistently slower at name resolution in a way that only mattered in production traffic patterns.

The fix wasn’t heroic: they moved that service back to Debian-slim while they tested resolver settings and reduced search domains.
Latency normalized immediately. Later, they revisited Alpine with a dedicated test harness and explicit resolver configuration. But the lesson stuck:
base image changes are runtime behavior changes, not cosmetics.

Mini-story #2: The optimization that backfired

Another org wanted faster builds and fewer scanner alerts. Someone proposed a single standard: “Everything on Alpine. Uniformity means less toil.”
They updated a dozen services, including Python data-processing jobs that ran hourly and were “simple enough.”

The first pain appeared in CI: installs took longer because packages that used to be wheels became source builds. To make it pass, engineers added
build dependencies: compilers, headers, and enough toolchain to make a small Linux distribution blush. The Dockerfiles grew complex. Cache misses
got more expensive.

Then it hit production: a change in a native dependency caused subtly different performance. Nothing exploded. It just got slower. The job started
overlapping with the next scheduled run, which increased load on the shared database, which slowed other services. Nobody could point at a single
failing request. Everything was “kind of worse.”

They eventually split the fleet: pure services with static binaries got minimal images; Python/Node services returned to Debian-slim with multi-stage
builds and aggressive dependency pinning. Uniformity was replaced with a smaller standard: “Choose compatibility by default; optimize only where it
matters.” Boring. Effective.

Mini-story #3: The boring but correct practice that saved the day

A platform team enforced a policy that sounded tedious: every service must have (1) a build stage, (2) a runtime stage, and (3) an optional debug
tag that contains troubleshooting tools and matches the runtime libc.

One Friday, a payment-adjacent service began failing TLS handshakes to a third-party endpoint. The vendor had rotated an intermediate CA.
The service was fine in one cluster and broken in another, which is how you get a weekend.

Because they had a debug image variant, on-call could attach it and immediately inspect the certificate chain, CA bundle versions, and OpenSSL behavior
without rebuilding images mid-incident. They confirmed the runtime image in the failing cluster had an older CA bundle because of a pinned base digest
that hadn’t been rebuilt in weeks.

The fix was dull: rebuild and redeploy with the updated base image and CA certificates, then add a policy to rebuild weekly even with no code changes.
The incident ended fast because the team invested in the unsexy parts: repeatable builds and predictable debugging.

Practical tasks: commands, outputs, and decisions (12+)

These are real commands you can run today. Each one is paired with what the output means and what you do next. This is how you stop arguing in PRs
and start making evidence-based decisions.

Task 1: Identify the base image lineage

cr0x@server:~$ docker image inspect myapp:latest --format '{{.Id}} {{.RepoTags}}'
sha256:2c9f3d2a6b1f... [myapp:latest]

What it means: You have the immutable image ID. Tags lie; IDs don’t.

Decision: Use the ID in incident notes and compare it to what CI built. If prod isn’t running the same ID, stop diagnosing and fix deployment drift.

Task 2: Confirm whether it’s musl or glibc

cr0x@server:~$ docker run --rm myapp:latest sh -c 'ldd --version 2>&1 | head -n 1'
musl libc (x86_64) Version 1.2.4

What it means: musl libc: you’re effectively in Alpine territory even if the image isn’t literally alpine:tag.

Decision: If you’re running prebuilt vendor binaries or Python/Node native modules, assume compatibility risk. Consider moving to Debian-slim or rebuilding dependencies appropriately.

Task 3: Check OS release metadata

cr0x@server:~$ docker run --rm myapp:latest sh -c 'cat /etc/os-release'
PRETTY_NAME="Alpine Linux v3.20"
NAME="Alpine Linux"
ID=alpine
VERSION_ID=3.20.2

What it means: You know the actual distro and version—useful for CVE discussions and reproducibility.

Decision: Pin a major/minor base version (or better, a digest) and schedule rebuilds. “latest” is how you get surprise upgrades.

Task 4: Measure image size properly (compressed and uncompressed)

cr0x@server:~$ docker image ls myapp:latest --format 'REPO={{.Repository}} TAG={{.Tag}} SIZE={{.Size}}'
REPO=myapp TAG=latest SIZE=146MB

What it means: Docker shows a size that’s influenced by layers and compression, not just “what you ship.”

Decision: If you’re optimizing size, focus on dependency bloat and build layers; don’t switch libc as a first move.

Task 5: See what changed across layers

cr0x@server:~$ docker history myapp:latest --no-trunc | head -n 6
IMAGE          CREATED        CREATED BY                                      SIZE      COMMENT
2c9f3d2a6b1f   2 days ago     /bin/sh -c apk add --no-cache curl bash         13.2MB
9a1d4f0c1e22   2 days ago     /bin/sh -c adduser -D -g '' app                 3.1kB
b17c11d9fba0   2 days ago     /bin/sh -c #(nop)  COPY file:... in /app        62.4MB
4f2a1c0f2d9e   3 weeks ago    /bin/sh -c #(nop)  FROM alpine:3.20             5.6MB

What it means: You can spot “we installed curl and bash in prod” and other slow creep.

Decision: Move debugging tools to a debug image; keep runtime lean and controlled.

Task 6: Verify CA certificates are present (TLS failures love missing CAs)

cr0x@server:~$ docker run --rm myapp:latest sh -c 'ls -l /etc/ssl/certs | head'
total 84
-rw-r--r--    1 root     root          1477 Oct  2  2025  ca-certificates.crt
drwxr-xr-x    2 root     root          4096 Oct  2  2025  java

What it means: There’s a cert bundle; at least the basics exist.

Decision: If outbound HTTPS fails, inspect the bundle date/version and confirm your runtime is updating it regularly.

Task 7: Reproduce a TLS handshake and see the chain

cr0x@server:~$ docker run --rm myapp:latest sh -c 'echo | openssl s_client -connect api.example.com:443 -servername api.example.com 2>/dev/null | openssl x509 -noout -issuer -subject | head -n 2'
issuer=CN = Example Intermediate CA, O = Example Corp
subject=CN = api.example.com

What it means: You can see what CA is used and whether your container can even run OpenSSL tooling.

Decision: If your base image lacks tooling, add a debug image or ship minimal tools. Don’t wait until the incident.

Task 8: Inspect DNS resolver configuration inside the container

cr0x@server:~$ docker run --rm myapp:latest sh -c 'cat /etc/resolv.conf'
nameserver 10.96.0.10
search default.svc.cluster.local svc.cluster.local cluster.local
options ndots:5

What it means: High ndots + multiple search domains can create extra queries and latency.

Decision: If you see DNS timeouts under load, reduce search domains or adjust ndots at the platform level; be extra cautious on musl-based images.

Task 9: Time DNS queries from inside the container

cr0x@server:~$ docker run --rm myapp:latest sh -c 'time getent hosts api.example.com | head -n 1'
203.0.113.10 api.example.com

real    0m0.043s
user    0m0.000s
sys     0m0.002s

What it means: getent uses the system resolver path. This is a good first approximation of DNS behavior.

Decision: If resolution is slow, don’t profile your app yet. Fix DNS or resolver behavior first.

Task 10: Confirm whether a binary is dynamically linked (and to what)

cr0x@server:~$ docker run --rm myapp:latest sh -c 'file /app/myapp'
/app/myapp: ELF 64-bit LSB pie executable, x86-64, dynamically linked, interpreter /lib/ld-musl-x86_64.so.1, stripped

What it means: It’s dynamically linked to musl. You can’t pretend this is “portable Linux.” It’s musl Linux.

Decision: If you want maximum portability and predictable behavior, build a glibc-targeted binary and run on Debian-slim, or go fully static with known tradeoffs.

Task 11: Detect missing shared libraries at runtime

cr0x@server:~$ docker run --rm myapp:latest sh -c 'ldd /app/myapp | tail -n 3'
libpthread.so.0 => /lib/libpthread.so.0 (0x7f1f0c4a0000)
libc.musl-x86_64.so.1 => /lib/ld-musl-x86_64.so.1 (0x7f1f0c6a0000)
Error relocating /app/myapp: __strdup: symbol not found

What it means: You’ve hit a symbol mismatch—classic libc/ABI trouble.

Decision: Stop forcing it. Move the runtime to Debian-slim (glibc) or rebuild the binary specifically for musl and test thoroughly.

Task 12: Check whether your “slim” image still has shells and tooling

cr0x@server:~$ docker run --rm debian:bookworm-slim sh -c 'command -v bash || echo "bash missing"; command -v curl || echo "curl missing"'
bash missing
curl missing

What it means: Debian-slim is not “full Debian.” It’s intentionally sparse.

Decision: If you require tools, install them explicitly or rely on a debug image. Don’t assume they exist.

Task 13: Compare package inventory (useful for scanner noise and attack surface)

cr0x@server:~$ docker run --rm alpine:3.20 sh -c 'apk info | wc -l'
14

What it means: Very few packages in a baseline Alpine image.

Decision: If you later see 120+ packages, you’re not “minimal” anymore. Revisit your Dockerfile and split build vs runtime stages.

Task 14: Validate you can patch the base image without code changes

cr0x@server:~$ docker build --pull --no-cache -t myapp:rebuild .
...snip...
Successfully built 6c1a1a7f9f19
Successfully tagged myapp:rebuild

What it means: You can rebuild from fresh base layers. This is how you pick up CA updates and security fixes.

Decision: If rebuilds fail or take hours, fix the build pipeline. Patching must be boring.

Joke #2: “We can’t rebuild right now” is the container equivalent of “the fire alarm is loud, can we mute it?” It’s not a plan.

Fast diagnosis playbook

When a containerized service misbehaves after a base image change (or during a migration), you need a fast, repeatable sequence.
Don’t start with CPU profiling. Start with the boring layers that break first.

First: confirm what is actually running

• Image ID in prod vs what you think you deployed. If they differ, stop and fix deployment drift.
• OS + libc inside the container: Alpine/musl or Debian/glibc. This narrows failure modes immediately.
• Entrypoint and command: ensure you didn’t lose bash and break scripts, or change working directories.

Second: validate network basics inside the container

• DNS resolution time using getent for critical hostnames.
• TLS handshake to key endpoints. Look for CA errors and chain differences.
• Proxy variables (HTTP_PROXY, NO_PROXY) and resolver config.

Third: validate runtime dependencies and linking

• Shared libraries: run ldd and look for “not found” or relocation errors.
• Language runtime compatibility: Python wheels, Node native modules, Java cert stores, font packages.
• Timezones/locales if the symptom is “only fails in region X” or “timestamps wrong.”

Fourth: only then measure performance

• Request latency breakdown: DNS, connect, TLS, upstream time.
• CPU vs I/O: confirm if the base image change caused different code paths (e.g., crypto backend) or just moved bottlenecks.
• Build reproducibility: if performance changed, confirm the artifact is identical besides the base layer.

Common mistakes: symptom → root cause → fix

1) “Exec format error” or “not found” when the file clearly exists

Symptom: Container starts and immediately fails with “no such file or directory” for a binary that is present.

Root cause: Missing interpreter/loader or wrong libc ABI (glibc-linked binary on musl image), or wrong architecture.

Fix: Run file and ldd inside the image. If it expects glibc, move to Debian-slim or rebuild for musl/static.

2) TLS fails only in some environments

Symptom: “x509: certificate signed by unknown authority” or handshake failures after vendor rotates intermediates.

Root cause: Outdated CA bundle or mismatched cert store behavior (especially across different base images).

Fix: Ensure ca-certificates is installed; rebuild images regularly; validate with openssl s_client in a debug image.

3) DNS timeouts that vanish when you retry

Symptom: Sporadic timeouts resolving service names; retries help but load increases.

Root cause: Resolver/search domain/ndots behavior interacting with musl; or cluster DNS under pressure amplified by extra lookups.

Fix: Measure resolution time with getent; reduce search domains; tune ndots; consider Debian-slim if behavior differs and you need predictable glibc resolver behavior.

4) Node/Python dependencies suddenly compile in CI and builds slow down

Symptom: Build time spikes; new dependencies on compilers and headers; flaky builds.

Root cause: Prebuilt artifacts target glibc; on musl you fall back to source builds.

Fix: Use Debian-slim for these workloads, or explicitly pin and build artifacts in a controlled builder stage. Don’t “apk add build-base” into production images.

5) “Works in slim, fails in alpine” shell scripts

Symptom: Entrypoint scripts fail on Alpine with different sed, grep, date behavior.

Root cause: BusyBox utilities differ from GNU coreutils; scripts rely on non-POSIX flags.

Fix: Make scripts POSIX-compliant or install the needed GNU tools explicitly; better: avoid shell glue in runtime images where possible.

6) CVE counts exploded after switching to Debian-slim

Symptom: Security scanner shows more findings; management panics.

Root cause: More packages installed and more metadata matches; not automatically higher exploitable risk.

Fix: Triage by runtime exposure and fix availability. Reduce packages via multi-stage builds. Track rebuild cadence and pin digests.

7) “Minimal” images that are actually not minimal

Symptom: Alpine image ends up larger than Debian-slim after adding build toolchains, shells, and debugging tools.

Root cause: Using Alpine as a shortcut instead of doing proper multi-stage separation.

Fix: Split build/runtime stages. Keep only runtime libs and app artifacts in the final stage.

Checklists / step-by-step plan

Checklist A: Choose the base image (production default)

1. List runtime dependencies: native libs, vendor binaries, language extensions, SSL/TLS needs.
2. If any dependency is “binary from the internet,” default to Debian-slim.
3. If the service is a single static binary and you can prove it: Alpine is acceptable.
4. Decide now how you will debug: debug image, ephemeral debug containers, or minimal tools in runtime.
5. Pin the base image by digest or by a strict version policy. Schedule rebuilds.

Checklist B: Build pipeline that won’t betray you

1. Use multi-stage builds: builder stage has compilers; runtime stage does not.
2. Make builds deterministic: pin dependencies; avoid “curl | sh” installers.
3. Run a smoke test inside the built image: DNS lookup, TLS handshake, binary execution.
4. Produce a debug tag that matches the runtime libc (musl debug tools for musl, glibc debug tools for glibc).
5. Rebuild images on a schedule, even without code changes, to pick up CA and security updates.

Checklist C: Before you migrate to Alpine

1. Run ldd on every binary you ship or download.
2. Test DNS resolution behavior under load in an environment that matches prod resolv.conf.
3. Validate TLS to every external dependency with current CA bundles.
4. Confirm your language ecosystem supports musl without surprise source builds.
5. Decide how you’ll handle “we need tcpdump” moments (hint: not by rebuilding in prod).

FAQ

1) Is Alpine “more secure” because it’s smaller?

Smaller can reduce the number of packages that can be vulnerable, but security is mostly about patch speed, rebuild automation, and runtime controls.
Alpine can be secure. Debian-slim can be secure. The insecure option is the one you don’t rebuild.

2) Why do scanners show fewer CVEs on Alpine?

Many scanners map CVEs to package names/versions. Fewer packages means fewer matches. That’s a signal, not a verdict. Focus on exploitable paths and patchability.

3) Does Debian-slim make my image huge?

Not if you use multi-stage builds and keep build tools out of runtime. Plenty of Debian-slim production images are small because the app and its runtime dependencies dominate size, not the base.

4) Can I run glibc apps on Alpine by installing glibc?

You can, but now you’re maintaining a hybrid environment with more edge cases. If your workload needs glibc, it’s usually cheaper and safer to run Debian-slim.

5) What about distroless images?

Distroless can be great for reducing runtime surface area, especially for static binaries or well-understood runtimes. But you must have a debug story. Distroless without a debug path is operational debt.

6) Why do Node native modules hate Alpine?

Many prebuilt Node modules are compiled against glibc. On Alpine (musl), you often compile from source, needing compilers and headers. That increases build time and complexity.

7) Is musl “worse” than glibc?

No. It’s different. musl is lean and standards-minded. glibc is compatibility-maximal. In production, compatibility with the broader ecosystem is often the winning attribute.

8) Should I standardize on one base image across the company?

Standardize on a decision framework, not a single image. A single base image for everything sounds tidy until you hit a runtime that needs different assumptions. Provide approved options: Debian-slim default, Alpine for static binaries, distroless where appropriate.

9) How often should we rebuild images if code doesn’t change?

Weekly is a common operational compromise: frequent enough to pick up CA and security updates, not so frequent that you drown in noise. The right answer depends on your risk posture and automation maturity.

Next steps (do this Monday)

1. Pick a default: Debian-slim for most services; Alpine only for static binaries and tightly controlled dependency graphs.
2. Add a debug variant: a sibling image/tag with basic network and TLS tools that matches your runtime libc.
3. Implement a rebuild cadence: rebuild and redeploy base images regularly; stop treating base layers as “set and forget.”
4. Instrument the boring stuff: DNS latency, TLS errors, and upstream connect times. These are the first things that differ across base images.
5. Write down the rule: “We choose base images for compatibility and operability first; size is a second-order optimization.” Put it in your platform docs and enforce it in reviews.

The best base image is the one that doesn’t turn routine failures into mysteries. Alpine can be that image. Debian-slim can be that image.
But if you pick based on vibes and megabytes, production will educate you—expensively.