# Flask on Ubuntu 24.04: Why Your Simple Install Broke at 2 AM

It was 2:47 AM when the alert hit. Our uWSGI workers on the new Ubuntu 24.04 staging box had started swapping. Not throttling, not complaining, full memory-pressure swap thrashing that turned a simple health check into a 12-second GET request. Load average read 8.4 on a 2-core instance with 8GB RAM, and half of that was occupied by a dependency graph that should have been lightweight by design.

I opened the box and ran `pip freeze`. Forty-seven packages, for an application whose actual codebase spanned three files. The smoking gun was Werkzeug 2.3.x lurking alongside Flask 3.0.3, pulled in as a transitive dependency from some abandoned middleware package that had not been updated since 2022. Werkzeug 2.x is incompatible with Flask 3.x at the API layer. The import chain resolved to the wrong package. Nobody noticed until the OOM killer started writing to syslog.

This is not hypothetical. This is what happens when you treat dependency installation as ritual rather than engineering.

## The Architecture You Are Actually Installing

Ubuntu 24.04 ships Python 3.12. Flask 3.x depends on Werkzeug 3.0, Jinja2, click, itsdangerous, blinker, and importlib-metadata. That is the clean version, the version you get when you stop letting pip's resolver guess.

Werkzeug 3.0 introduced breaking changes to `werkzeug.serving` and removed legacy path-info parsing. If you install Flask via `apt install python3-flask`, you will almost certainly receive a distro-pinned Werkzeug 2.x, because Ubuntu's LTS cycle moves slower than PyPI's release cadence. The result is an environment where `import flask` succeeds silently, but routing breaks under production load because the WSGI server calls methods that no longer exist on the werkzeug object. You will spend six hours debugging route mismatches before checking `werkzeug.__version__`.

## The Correct Installation Path

Navigate to your project root. Never install anything inside `/usr/lib/python3/dist-packages/`. That directory belongs to apt, not to you.

The `venv` module implements PEP 405 isolation. When activated, it prepends `venv/bin` to PATH and sets `VIRTUAL_ENV`. Every subsequent `pip install` targets the sandbox exclusively. This matters because the most common production failure is coexistence of `python3-flask` from apt alongside a pip-installed Flask. Python's `sys.path` precedence rules mean the system package can shadow the virtualenv during import resolution, and behavior is non-deterministic across Python versions.

**Verification with failure walkthrough:**

Expected output confirms isolation:

If any path resolves to `/usr/lib/python3/dist-packages/`, your venv activation failed or was overridden. Fix the shell state before continuing.

Generate a deterministic lockfile:

## Race Condition Resilience

Two race conditions silently destroy Flask deployments on Ubuntu 24.04.

**Race 1: Concurrent pip installs corrupting site-packages.** If two deployment scripts run simultaneously, they can interleave writes to the same `__pycache__` directory, producing corrupted `.pyc` files that raise `ImportError` only under specific import orders. Mitigate with file-level locking:

Call this wrapper from your deployment pipeline:

**Race 2: systemd service start competing with gunicorn worker bootstrap.** If `systemctl restart` fires before all workers finish initializing their import chains, you get partial reloads where some workers hold stale imports. Fix with readiness probes:

## Memory Profiling on 8GB RAM Instances

Flask itself consumes approximately 50MB when loaded. The problem is never Flask. The problem is everything pip decided to pull in alongside it, plus the unbounded pip cache that grows with every install command.

For containerized deployments, add these environment variables to your Dockerfile:

This eliminates the pip cache layer entirely, saving 200MB to 400MB per build, and ensures deterministic stderr output during container startup. On an 8GB instance running gunicorn with multiple worker processes, that memory budget determines whether you scale horizontally or burn through your RAM allocation before lunch.

Validate the freeze file produces exactly 10 to 12 entries under normal conditions. Anything above 20 suggests transitive dependency bloat from an overly broad install specification. Strip unused packages proactively:

## Validating the Installation

Run this health check script before considering the environment ready for deployment:

in_venv = sys.prefix != sys.base_prefix
results.append(("Virtualenv active", in_venv))
print(f"  Prefix: {sys.prefix}")

for mod in ["flask", "werkzeug", "jinja2", "click", "itsdangerous"]:
    spec = importlib.util.find_spec(mod)
    ok = spec and "/venv/" in (spec.origin or "")
    results.append((mod, ok))
    if spec:
        print(f"  {mod:12s} -> {spec.origin}")

try:
    import flask
    ver = flask.__version__
    parsed = tuple(int(p) for p in ver.split(".")[:2])
    results.append((f"Flask >= 3.0", parsed >= (3, 0)))
except Exception as e:
    results.append(("Flask version", False))
    print(f"  !! Version check error: {e}")

try:
    import werkzeug
    wv = tuple(int(p) for p in werkzeug.__version__.split(".")[:2])
    ok_w = wv >= (3, 0)
    results.append((f"Werkzeug >= 3.0", ok_w))
except Exception:
    results.append(("Werkzeug", False))

# Memory check, flag environments exceeding 150MB at import time
tracemalloc.start()
import flask as _
_, current = tracemalloc.get_traced_memory()
tracemalloc.stop()
usage = resource.getrusage(resource.RUSAGE_SELF)
rss_mb = usage.ru_maxrss // 1024
mem_ok = rss_mb < 150
results.append((f"RSS < 150MB ({rss_mb}MB)", mem_ok))

print("\n=== Health Report ===")
all_pass = True
for name, ok in results:
    status = "PASS" if ok else "FAIL"
    print(f"  [{status}] {name}")
    if not ok:
        all_pass = False

sys.exit(0 if all_pass else 1)

## The Deployment Boundary

Flask is a micro-framework. It provides routing, templating, and request context management. It does not provide production WSGI serving. The dev server is single-threaded, lacks connection pooling, has no graceful shutdown hooks, and cannot handle MPM. Exposing it directly is how you create the exact outage profile that triggered this article.

Development uses the Flask dev server. Staging uses gunicorn behind nginx reverse proxy. Production uses gunicorn with eventlet workers, nginx for TLS termination, and systemd for process supervision with cgroup memory limits. This separation of concerns is non-negotiable.

Reference the production MVP architecture blueprint for deployment topology comparisons across different cloud instance sizes, these patterns are based on actual production builds handling real traffic, not theoretical benchmarks.

What dependency resolution nightmare have you inherited from a previous engineer who thought `pip install Flask` was sufficient?