Network Ips, docker range

 /24 what does it mean?

first 24 bits of the IP address belong to the network portion, leaving the remaining 8 bits for individual devices (hosts).

so there will be total of 256 ips for 8 bits 

because 8 bits equals 256 because each bit has 2 possible states

2^8 = 256

1. The Total Count (256 Possibilities)

An 8-bit system has 8 binary slots, and each slot can be either a 0 or a 1. To find the total number of unique combinations, you calculate 2⁸, which equals 256. This means an 8-bit number can represent 256 distinct values.

2. The Maximum Value (255)

Because computers are digital systems, they start counting from 0 rather than 1.

• The lowest possible value is all zeros: 00000000 (which equals 0).
• The highest possible value is all ones: 11111111 (which equals 255).

If you count all the numbers from 0 to 255, you get exactly 256 total numbers.

• The lowest possible 8-bit number is 00000000 (which is 0).
• The highest possible 8-bit number is 11111111 (which is \(128 + 64 + 32 + 16 + 8 + 4 + 2 + 1 = 255)

 addresses in a network  =  2^(32 − N)

   /24  →  2^(32−24)  =  2^8  =  256      ✓ matches your count
   /28  →  2^(32−28)  =  2^4  =   16

Why it splits into 16

Carving a /24 into /28s means taking 4 more bits away from the host part:

   169.254.6.0/24    11111111.11111111.11111111 . 00000000
                                               └── 8 host bits ──┘
                                                    2^8 = 256 addresses

   169.254.6.0/28    11111111.11111111.11111111 . 1111 . 0000
                                               └─4─┘   └─4──┘
                                          new subnet    host bits
                                          bits: 2^4     = 2^4 = 16
                                              = 16        addresses
                                              subnets     each

asdad

"bip": "169.254.4.1/28",
"default-address-pools": [ { "base": "169.254.6.0/24", "size": 28 } ]

Two separate knobs, and they're easy to conflate:

Key	Meaning
base	the total space Docker may carve up
size	the prefix length of each network it creates — not the number of networks

So size: 28 means every auto-created network is a /28. The base then divides evenly:

169.254.6.0/24  ── 256 addresses, sliced into /28 ──
├── 169.254.6.0/28      ← network 1
├── 169.254.6.16/28     ← network 2
├── 169.254.6.32/28     ← network 3
│   ⋯
└── 169.254.6.240/28    ← network 16

asdsad

sa

16 is the block size. Not all 16 are assignable:

   169.254.9.0/28
   ├── .0    network address    ← not assignable
   ├── .1    gateway            ← Docker takes it
   ├── .2 … .14   13 container slots
   └── .15   broadcast          ← not assignable

   block = 16  ·  usable hosts = 14  ·  after the gateway = 13

asdsadasd Docker colloision

ip route get 172.17.0.5

   BEFORE                                AFTER  (a stack comes up on 172.17.0.0/16)
   ─────────────────────────────         ────────────────────────────────────────
   default         via 172.19.11.1       172.17.0.0/16   dev docker0   ← NEW, /16 > /0
   169.254.0.0/16  enp0s31f6             172.19.11.0/24  enp0s31f6
   172.19.11.0/24  enp0s31f6             169.254.0.0/16  enp0s31f6
                                          default         via 172.19.11.1

   packet ─→ gateway ─→ LAN ─→ 172.17.0.5        packet ─→ docker0 ─→ ARP ─→ nobody
              ✓ SYN arrives                                  ✗ dies. 172.17.0.5
                                                               never saw a packet.

asdadad cooliosn B 

 Docker created a network on 172.19.11.0/28   ← contains 172.19.11.1

   main table                            local table = "addresses I answer for"
   ───────────────────────────           ──────────────────────────────────────
   172.19.11.0/28  br-18191aa6  ← NEW    local 172.19.11.161  dev enp0s31f6
   172.19.11.0/24  enp0s31f6             local 172.19.11.1    dev lo       ← NEW
   default         via 172.19.11.1
                                         the host now thinks the GATEWAY is itself

   packet for 8.8.8.8 ─→ default via 172.19.11.1 ─→ look up .1 ─→ "that's me"
                                                       └─→ delivered to lo ─→ ✗

why colliosnn 

 ── inside the host (nothing on the wire yet) ──      ── on the wire ──
   ───────────────────────────────────────────────      ─────────────────

   1.  app: send() to 8.8.8.8
   2.  routing table: which interface?
         8.8.8.8 is not in 172.19.11.0/24
         → default route → next hop 172.19.11.1, dev enp0s31f6
   3.  routing table AGAIN: how do I reach 172.19.11.1?
         it IS in my /24 → on-link → ARP for it
   4.  ARP: who has 172.19.11.1?  →  00:09:0f:09:6f:1a
   5.  build the ethernet frame:
         dst MAC = 00:09:0f:09:6f:1a   ← the gateway
         dst IP  = 8.8.8.8             ← unchanged
                                                     ────→ gateway ──→ … ──→ 8.8.8.8

asdadadsadasdsad ssh colliosn 

 you: 172.19.11.160                    host: 172.19.11.161  (sshd :22)
   ──────────────────                    ──────────────────────────────

   1.  SYN ───────────────────────────→  arrives on enp0s31f6
                                          ← no routing decision needed.
                                            A packet that arrives, arrives.
   2.                                       kernel accepts. sshd replies.
   3.                                       route lookup for 172.19.11.160
                                            ← ★ THIS is where it dies
   4.  SYN-ACK ←─────────────────────────   (or doesn't)

three way ssh colliosn 

   ── A ── your address falls inside a range Docker claimed
   ─────────────────────────────────────────────────────────
   reply to 172.19.11.160  →  matches 172.19.11.0/24 → enp0s31f6   ✓
   reply to 172.19.11.5    →  matches 172.19.11.0/28 → br-xxxx     ✗
                              (Docker took .0/28; .5 is inside it)

   ── B ── you're off-subnet, and the gateway got shadowed
   ─────────────────────────────────────────────────────────
   reply to 10.20.30.40    →  off-link → default via 172.19.11.1
                              → lookup .1 → "local, dev lo" → loopback   ✗

   ── C ── rp_filter = 1 (strict)
   ─────────────────────────────────────────────────────────
   SYN arrives on enp0s31f6. Kernel checks: would I send *back* to
   this source via enp0s31f6?  A Docker route now says "no, via docker0"
   → packet dropped BEFORE sshd ever sees it.      ✗
   (this host is at rp_filter=2, so it's spared)

asdadasdasdsad host vs brdige(host dangerous)

docker0 — yes, with one trap that catches everyone

The trap is a naming collision: bridge is both a driver and the name of one specific network.

   driver "bridge"        ← the technology. docker0 AND every br-xxxx use it.
   network named "bridge" ← docker0 specifically. The default one.
   network_mode: bridge   ← attach to docker0.

So this lands you on docker0:

services:
  app:
    network_mode: bridge      # explicit

And this does not — it silently creates a user-defined bridge called <project>_default:

services:
  app:
    networks: [default]       # ← its own br-xxxx, NOT docker0

Compose's auto-created default network is a user-defined bridge. Every compose stack on this host proves it:

   docker network ls
   bridge                              ← docker0. linkdown. empty.
   umami_default                       ← user-defined, br-ba9f53a61dc4

That's why docker0 is linkdown here — nothing has ever asked for it.

you write	you get	gateway
network_mode: bridge	docker0	bip
nothing / networks: [default]	<project>_default (own br-xxxx)	subnet + 1
an explicit networks: block	one br-xxxx per network	subnet + 1
network_mode: host	none	none

User-defined is strictly better, which is why docker0 is effectively legacy:

• DNS by name — on a user-defined network, db resolves to the container. On docker0 you need --link (deprecated) or hardcoded IPs. That's why umami-umami-1 can just say db in its connection string.
• Isolation between networks — Docker inserts DOCKER-ISOLATION rules so certgen-net can't reach umami_default. The default bridge is more permissive.
• Hot attach/detach without restarting containers.

2. network_mode: host — yes, genuinely dangerous

It removes the boundary entirely. The container doesn't get its own network namespace; it shares the host's.

   ── bridged ──                          ── host mode ──
   ┌─ container netns ─┐                  ┌────────────────────────┐
   │ eth0 169.254.9.3  │                  │  container process     │
   └────────┬──────────┘                  │  lives in the HOST's   │
            │ veth                        │  network namespace     │
   ┌────────▼──────────┐                  │                        │
   │ br-ba9f53a61dc4   │ ← boundary       │  binds :443, :22, :80  │
   └────────┬──────────┘                  │  reaches 127.0.0.1     │
            │ iptables NAT + isolation    │  sees the whole LAN    │
   ┌────────▼──────────┐                  └───────────┬────────────┘
   │ host 172.19.11.161│                              │
   └───────────────────┘                  no boundary. it IS the host.

sadsadad

mode        allocates an IP?          from where              can it take .161?
   ─────────   ───────────────────────   ─────────────────────   ─────────────────
   host        no                        —                       only if the host
                                                                 already has it
   bridge      yes                       169.254.x.0/28 (Docker)  no
   macvlan     yes                       your LAN subnet          yes — and that's
                                                                 a duplicate-IP bug

asdsad using host mode no longer uses bips, container just seperate themself by taking over real host ports

   HOST MODE × 3
   ─────────────

   ┌──────────────────────────────────────────────────────┐
   │  the host's single network namespace                 │
   │                                                      │
   │   enp0s31f6   172.19.11.160/24                       │
   │                                                      │
   │   :80    ← container A                               │
   │   :8080  ← container B                               │
   │   :9000  ← container C                               │
   │                                                      │
   │   no eth0 for any of them. no address. no veth.      │
   │   A, B and C reach each other on 127.0.0.1           │
   └──────────────────────────────────────────────────────┘

   from the LAN, all three answer to the SAME address:

     172.19.11.160:80     172.19.11.160:8080     172.19.11.160:9000
     └──────────────── one IP, three ports ────────────────┘

The port becomes the only thing that tells them apart

   BRIDGED × 3                          HOST MODE × 3
   ───────────                          ─────────────
   ┌─A─┐ ┌─B─┐ ┌─C─┐                    ┌──────────────────────┐
   │.2 │ │.3 │ │.4 │  ← own addresses   │  :80  :8080  :9000   │
   └─┬─┘ └─┬─┘ └─┬─┘                    │  ← only ports differ │
     └─────┼─────┘                      └──────────────────────┘
       br-xxxx (169.254.9.1)
           │
     host 172.19.11.161

asdasda

and no host to docker port mappings

How to add to sudo

# add user to sudo group

 sudo usermod -aG sudo username

# If it doesnt work user must be add to the allowed sudo file 

sudo EDITOR=vim visudo

@includedir /etc/sudoers.d
<your_user_name> ALL=(ALL) NOPASSWD:ALL

PORT FORWARDING so local port can forward to remote port

 ssh -N -L <port>:127.0.0.1:<port> <user>@<host>

Privelege port and docker user creation and permission

 biding to port < 1024 such as 443 need root permission

docker is always run by root so no issue 

Dockerfile:  adduser -D -u 10001 myprojectuser      (in-image account, name exists only inside)
             USER 10001                       (default if compose says nothing)

compose:     user: "${gID:-10001}:${uID:-10001}"   (OVERRIDES the image's USER -> myprojectuser)

kernel:      checks NUMBERS ONLY against mounted-file owners — no names cross the boundary

Scenario	Container runs as	Host logs/ written by	joey's access
.env has gID/uID = joey's ids	700198504 (myprojectuser ignored)	joey	full — owner
.env unset → fallback 10001	10001 (myprojectuser )	nameless 10001	read only (644/755) — can't create/delete/chown

Two wording refinements to your summary

1. "mapped" isn't quite the mechanism — there's no mapping table. When the container (10001) writes to the mount, the number 10001 lands in the host inode's owner field directly; the host just displays it namelessly because no account has it. Nothing is translated in either direction.

2. "myprojectuser is ignored" is about the account, not the permissions — when you set joeyids, the image's USER 10001 and the myprojectuser passwd entry are bypassed entirely, but the files in the image still work for joey because we chmod -R a+rX /app in the Dockerfile (world-readable). That chmod is why any uid can run the app; the user: line only decides whose numbers touch the mounts.

So the practical rule you've derived is exactly right: pick the number in .env, and make the mounted dirs owned by that same number — either naturally (you own them, set your ids) or once (chown 10001:10001 logs), and cleanup for the nameless case is docker run --rm -v ./logs:/w alpine chown ... since any daemon user has root on mounts.

Docker image buildign

 docker image automatically uses only 1 alpine (1 light weight OS)

many alpine like go alpine or python alpine all come with a light weight linux OS,

the way to achieve is u use go alpine to build and export the finished binary

use python alpine to build and export finished dir

then copy both to new runtime alpine such as python aline(cause python need an interprotr)

# --- Stage 1: Go builder (offline: deps are vendored) ----------------------

FROM myhub.com/golang:1.26.2-alpine3.22 AS go-builder

WORKDIR /build

COPY srv/ ./srv/

COPY vendor/ ./vendor/

COPY go.mod go.sum ./

# CGO_ENABLED=0 -> static binary; -mod=vendor -> no network needed

RUN CGO_ENABLED=0 GOOS=linux go build -mod=vendor -o /edge ./srv/cmd/server

# --- Stage 2: Python builder — venv from lockfile, then strip source -------

FROM myhub.com/python:3.12-alpine AS py-builder

WORKDIR /app

COPY app/pyproject.toml app/uv.lock ./

RUN pip install --no-cache-dir uv \

 && uv sync --frozen --no-dev --no-install-project

COPY app/server.py ./

# Bytecode-only: compile server.py (and the whole venv) to .pyc next to the

# source, then delete every .py. Python imports .pyc seamlessly, so

# `uvicorn server:app` works unchanged; the app's source never ships.

RUN python -m compileall -b server.py && rm server.py \

 && python -m compileall -b -q .venv \

 && find .venv -name '*.py' -delete

# --- Runtime: same python image as the pyc builder -------------------------

# Using python:3.12-alpine as runtime (not bare alpine + apk python3) makes

# the venv's interpreter path (/usr/local/bin/python3) and the pyc bytecode

# format structurally identical to the builder — no version-skew bugs.

FROM myhub.com//python:3.12-alpine

# tzdata: logger pst_time needs America/Los_Angeles; ca-certificates: the

# edge and uvicorn call upstream Mantis over TLS.

RUN sed -i "s#dl-cdn.alpinelinux.org/alpine#jfrog.corp.fortinet.com/artifactory/apk_proxy#g" /etc/apk/repositories \

 && apk add --no-cache tzdata ca-certificates \

 && adduser -D -u 10001 mantis \

 && mkdir -p /app/logs /certs && chown -R mantis:mantis /app/logs /certs

COPY --from=go-builder /edge /edge

COPY --from=py-builder /app /app

# Files from the builders are root-owned; the runtime user (10001) needs

# read access to /app (server.pyc, venv). a+rX = readable, dirs traversable.

RUN chmod -R a+rX /app

USER 10001

WORKDIR /app

EXPOSE 8443

ENTRYPOINT ["/edge"]

---------------

ur image has three Alpines — and only one survives

FROM golang:1.26.2-alpine3.22   (stage 1: go-builder)  ──► discarded (only /edge extracted)

FROM python:3.12-alpine         (stage 2: py-builder)  ──► discarded (only /app copied out)

FROM python:3.12-alpine         (stage 3: runtime)     ──► THIS becomes the container

COPY --from=py-builder /app /app is the only thing crossing the boundary — it plucks the finished pyc-only venv out of that stage's filesystem. The go-builder's Go toolchain, its alpine userland, its whole filesystem: none of it exists in the final image. Not merged, not layered-on — discarded.

So "which alpine am I in" when you exec into the container

The last stage's one — verified just now by poking the running image:

/etc/os-release    → Alpine Linux

python3            → /usr/local/bin/python3   (the python:3.12-alpine layout — apk's would be /usr/bin/python3)

/bin/busybox       → present (alpine userland)

That path detail (/usr/local/bin vs /usr/bin) is actually the fingerprint distinguishing "python image's alpine" from "plain alpine + apk python" — and it was the exact bug from the first build: the venv symlinked to /usr/local/bin/python3, which the bare-alpine runtime didn't have. Choosing the same image for stage 2 and 3 made the builder/runtime OS boundary disappear entirely.

The rules that make this coherent

One runtime filesystem, period. A container = exactly one image's final layer stack. FROM stages before the last exist only at build time; docker exec / docker run can never see them.

COPY --from is the only door between stages. Files cross explicitly; nothing else carries over — not env vars, not users (hence the re-created mantis user in the runtime stage), not the OS's package database (the runtime stage doesn't "know" about the go-builder's apk installs).

They can even be different distros. A totally legal pattern: build in golang:alpine, run in debian:slim or ubuntu — or the reverse (build on glibc's debian, run on alpine musl = breakage). Nothing forces the bases to match. Ours deliberately match (alpine→alpine, same python image twice) to keep musl/pyc/symlinks consistent.

"Alpine" is not one monolithic thing. Each stage's FROM pins a different alpine snapshot: go-builder = alpine 3.22, python stages = whatever alpine 3.12-python image is built on (also 3.22-ish here). They coexist at build time, independent and unrelated at run time.

The practical checks when you're confused inside a container

cat /etc/os-release      # which distro userland this is

which python3            # /usr/local/bin → python image; /usr/bin → apk-installed

head -1 /app/.venv/bin/uvicorn   # shebang: which interpreter the venv expects

TL;DR: multiple alpines can coexist inside a Dockerfile (we have three), but the container is only the last one — verified above: the running container is the runtime-stage alpine with the python-image layout, and the other two alpines died when their build stages ended.

ENTRYPOINT vs CMD — the full picture

ENTRYPOINT CMD

Role The container's main process — what it is Default arguments to that process — how it's typically invoked

exec-form ENTRYPOINT ["/edge"] CMD ["--port", "8443"]

Shell-form ENTRYPOINT /edge (wraps in sh -c, breaks PID 1 signal semantics — avoid) CMD --port 8443 (same wrapping)

Overridden at runtime by docker run ... --entrypoint X (rare) docker run image <args> (common)

With both set runs as ENTRYPOINT + CMD concatenated

The four combinations, concretely for our image (ENTRYPOINT ["/edge"], no CMD):

What you run What actually executes

docker run mantis-mcp:latest /edge (entrypoint alone) — our case

docker run mantis-mcp:latest foo bar /edge foo bar — CLI args appended to the entrypoint

docker run --entrypoint /bin/sh mantis-mcp:latest /bin/sh — entrypoint replaced (our debugging trick all session: --entrypoint /bin/sh -c '...')

hypothetical ENTRYPOINT ["/edge"] + CMD ["--port","9000"] /edge --port 9000

Yes — it works, and you already have a perfect example on this box: the alpine image has no ENTRYPOINT, only CMD ["/bin/sh"] (verified above). docker run alpine starts /bin/sh as PID 1, which immediately hits EOF (no stdin attached, not interactive), exits 0, container ends.

CMD-only behavior

Without ENTRYPOINT, CMD alone defines the process:

CMD ["python", "server.py"]     # image with no ENTRYPOINT

What you run What executes as PID 1

docker run img python server.py (the CMD)

docker run img bash bash — CMD fully replaced

docker run img -c "echo hi" python -c "echo hi" — CMD's first word replaced, rest kept (the footgun)

So a CMD-only image is a perfectly normal container — certgen could have been written CMD-only and would run the same way.

Then why does ENTRYPOINT exist?

The distinction is override semantics — what survives when the user appends arguments:

user runs img args args become

CMD-only CMD replaced the whole new command — the program itself can be swapped

ENTRYPOINT+CMD ENTRYPOINT + args parameters to a fixed program — the program can't be swapped, only instructed

COPY --from=go-builder /edge /edge — both paths here are the binary file itself:

COPY --from=<stage> <SRC path in that stage> <DEST path in this stage>

             │                    │                      │

      py-builder/go-builder    /edge (the file         /edge (destination

      (named "go-builder"      that `go build          FILE in the runtime

      via `AS go-builder`)     -o /edge` made)         stage's filesystem)

The name is just what we chose: go build -o /edge ./srv/cmd/server in stage 1 wrote the compiled binary to a file called /edge; the COPY then plucks that one file into the runtime stage at the same path. If we'd written -o /edge/mcp-server, then /edge would be a directory containing a binary — but we didn't, so it's a single executable file at the filesystem root. (Compare: COPY --from=py-builder /app /app copies a directory — COPY copies whatever the source is, file or tree.)

Why the odd-looking syntax X X (same path twice)? The two /edges live in different filesystems: the first is a path inside the go-builder stage, the second is a path inside the runtime stage. They happen to be spelled the same; COPY --from=py-builder /app /app shows the identical pattern. A more descriptive spelling that means exactly the same thing:

COPY --from=go-builder /edge /usr/local/bin/edge   # dest is the file path, wherever you like

2. It's not run "with CMD" — it's run via ENTRYPOINT

Small but important, from the last discussion: the image has no CMD. What launches /edge is:

ENTRYPOINT ["/edge"]     ← names /edge as the container's main process (PID 1)

So the complete story across the three Dockerfile stages:

stage 1 (go-builder):   go build -o /edge ./srv/cmd/server    # COMPILE → /edge is created as a file

stage 3 (runtime):      COPY --from=go-builder /edge /edge    # TRANSPORT the file into the final image

                        ENTRYPOINT ["/edge"]                  # DECLARE: this file is what `docker run` execs

/edge is a file 

The chain you described, confirmed

/edge (PID 1) starts

  → config.Load() reads CHILD_CMD (among others)

  → childArgv = strings.Fields(CHILD_CMD)     ["…/uvicorn", "server:app", "--host", "127.0.0.1", …]

  → supervisor.Spawn(childArgv, CHILD_DIR)    fork + exec → uvicorn runs as child of /edge

So /app's Python stuff only exists on disk because of the COPY — it only runs because /edge reads CHILD_CMD and execs it. No env → no spawn → edge exits at startup (the fail-fast we mapped). And uvicorn's cwd is CHILD_DIR (default /app), which is why bare server:app resolves to /app/server.pyc — the module file sitting right there.

What happens with no CHILD_CMD — the default kicks in

config.go:

const defaultChildCmd = "/app/.venv/bin/uvicorn server:app --host 127.0.0.1 --port 8000 --proxy-headers --forwarded-allow-ips 127.0.0.1"

ChildCmd:  getEnv("CHILD_CMD", defaultChildCmd),   // ← .env value if present, else this

python bytecode python pyc vs py

 pyc advantage is faster on load, because its compiled, but it still requires a run time python interpretor, the main thing is others cant see ur source code directly and its a bit more diffcult to reverse engineer

server.py  →  server.pyc

A .pyc is the same Python interpreter executing a pre-parsed intermediate representation (bytecode for a stack VM), just skipping the compile-from-source step at import time. Nothing becomes an ELF binary:

server.py server.pyc Go binary (/edge)

What runs it python interpreter python interpreter (same) CPU directly

Form source text frozen bytecode + marshalled constants machine code

Readable as source? trivially no — only via decompiler, lossy no

This project dev only what the image ships yes

The venv's python process still interprets every line — exactly as before. The only mechanical differences: import finds server.pyc instead of server.py (both are equally importable), and startup is marginally faster (no parse/compile step). Zero behavior change.

The ladder, made concrete (since this was the source-visibility decision)

server.py     readable source            ← what a normal Python deploy ships

server.pyc    bytecode, decompilable     ← where we are (Dockerfile: compileall -b + delete .py)

Nuitka        transpiles to C → real ELF binary   ← the actual "make it a binary" option

Go rewrite    ELF binary                 ← the only *true* hiding, full rewrite of the app

.pyc protection is against casual reading — docker run ... cat /app/server.py fails because the file doesn't exist; strings server.pyc shows fragmented constants, not logic. A determined person with a decompiler (pycdc/uncompyle-style tools) can reconstruct most of it, though imperfectly — f-strings, comprehensions and some typing info come out mangled. That's the exact threat model you picked: "production shouldn't have readable Python," not "survive a hostile reverse-engineer."

If that bar ever rises, the escalation path (from the todo plan) is Nuitka — but that's a real bet: build complexity, fastmcp's decorator/introspection magic needs validation, and every dependency bump re-runs the compatibility test. The Go rewrite is the only total hiding, and we already chose it for the edge while keeping the app in Python deliberately.

One sharp edge worth knowing

.pyc files embed a magic number tied to the CPython minor version — server.pyc from 3.12 will refuse to run on 3.11/3.13. That's why the Dockerfile builds the pyc with the same image (python:3.12-alpine) that runs it, making the pairing structural rather than coincidental. It's also why you can't "just copy the venv" between hosts — irrelevant inside the immutable image, but remember it if you ever extract the venv for debugging on the prod host.

Bottom line: Dockerfile bytecode-only = source removed, bytecode kept — the interpreter still runs Python, just from a non-readable file. It's obfuscation-by-deletion: cheap, standard, fully reversible by you (git has the source), and sufficient for "the devops team can run it but shouldn't read it."

Exactly right on all three points — that's a precise summary. Expanding each slightly so the model is complete:

1. Interpreted at runtime — yes, same interpreter, same VM. The CPython execution model is two-stage: compile source → bytecode, then interpret bytecode on a stack machine. A .pyc just pre-computes stage one, shipping the frozen output of the compiler. At runtime, python server.pyc and python server.py execute the identical instruction stream — your decorators, async coroutines, the FastMCP tool dispatch — all still go through the interpreter's eval loop, instruction by instruction, just as before.

2. Slightly faster — but only at one specific moment: import time. The speedup is skipping lexing/parsing/codegen when the module loads. For this app that's milliseconds, once per process start. After import, zero runtime difference — same bytecode buffer, same eval loop, same speed. So it's a free side benefit, but if anyone asks "did we do this for performance?", the honest answer is no — it was for source-hiding; the perf delta is a rounding error.

3. Not readable without a decompiler — with a precise boundary on what "not readable" means:

Effort What they get

cat /app/server.pyc, strings fragmentary constants (strings, names), no logic — enough to spot a token or a URL, not to follow code

pip-installed decompiler (pycdc etc.) approximate source back, with real damage: f-strings, comprehensions, lambdas, and stripped type info come out garbled or missing

Determined reverse-engineering most business logic reconstructed

Also worth noting what doesn't hide at all: docstrings, comments... actually — docstrings survive into the .pyc verbatim (they're runtime objects), while comments do not exist in bytecode and vanish completely. So the bytecode hides your code but still leaks your prose (including anything sensitive accidentally left in a docstring, like the token example we saw in .env.example history). If you ever want prose scrubbed too, -OO at compile time strips docstrings/asserts:

python -m compileall -b -O2 ...

but you'd lose the helpful docstrings in tracebacks/debugging — not recommended for an app you still have to operate.

So the one-line mental model you've now got: .pyc = compiled for the interpreter, not to the machine — the hiding comes from the deleted source, the speed comes from the skipped compile, and the interpreter never stopped being the one doing the work. And in this image, all of Python — interpreter, stdlib, deps — is itself pyc-only too (find .venv -name '*.py' -delete), so the whole shipped surface is consistently bytecode, not just server.py.

FROM jfrog.corp.fortinet.com/docker-group/python:3.12-alpine AS py-builder

WORKDIR /app

COPY app/pyproject.toml app/uv.lock ./

RUN pip install --no-cache-dir uv \

 && uv sync --frozen --no-dev --no-install-project

COPY app/server.py ./

# Bytecode-only: compile server.py (and the whole venv) to .pyc next to the

# source, then delete every .py. Python imports .pyc seamlessly, so

# `uvicorn server:app` works unchanged; the app's source never ships.

RUN python -m compileall -b server.py && rm server.py \

 && python -m compileall -b -q .venv \

 && find .venv -name '*.py' -delete

docker entrypoint cmd

 entrypoint is in DockerFile of an image is what docker exec on start

CMD without entrypoint specified is same thing, docker exec CMD

if entrypoint and CMD both present, doccker exec entry point and treat CMD as input parameter to entrypoint

!!!!!!!!!!

ENTRYPOINT ["/bin/bash"] → yes, execve("/bin/bash"), bash is PID 1 ✓ (your intuition)

ENTRYPOINT ["/edge"] → execve("/edge"), the Go binary is PID 1 ✓

But it's never . — sourcing is a shell-only operation on shell-syntax files; 

Docker always execs, replacing the freshly cloned process's image with your program.