Dataface Tasks
    Heartbeat snapshot (JSON)

    Scope just server bindings by execution context

    IDM1-INFRA-003
    Statuscompleted
    Priorityp1
    Milestonem1-ft-analytics-analyst-pilot
    Ownerhead-of-engineering
    Completed bydave
    Completed2026-03-25

    Problem

    All just server recipes (playground, cloud, docs) bind to 0.0.0.0 regardless of execution context, exposing development servers to the local network when running on a developer's machine. This is unnecessary for local development and has been flagged as a security policy concern during code reviews. The 0.0.0.0 binding is only needed inside cbox containers where the host needs to reach the container's server. Without context-aware binding, developers must manually override the host or accept the blanket exposure, and reviewers repeatedly flag the same issue without resolution.

    Context

    • 12 justfile server recipes (evals, core, alie, cloud, playground, asql-playground, asql-docs, nimble, docs, plans) hardcode --host 0.0.0.0 or --dev-addr 0.0.0.0:PORT, exposing dev servers to the local network.
    • Only tasks already binds to 127.0.0.1.
    • The Procfile also uses 0.0.0.0 but that is for GCP/container deployment and should stay as-is.
    • The serve and worktree-serve orchestrator recipes already echo 127.0.0.1 URLs — but the underlying recipes they call still bind to 0.0.0.0, so the echo is misleading.
    • Container/cbox environments need 0.0.0.0 so the host can reach the container's server; local dev does not.

    Possible Solutions

    • A — Leave all recipes bound to 0.0.0.0: Simplest, but keeps avoidable LAN exposure and fails principle of least privilege. Reviewers keep flagging it.
    • B — Recommended: env-var-driven host default. Add a top-level host := env_var_or_default("DFT_HOST", "127.0.0.1") variable. All server recipes use {{host}}. Local dev gets loopback automatically; container environments set DFT_HOST=0.0.0.0.
    • C — Force loopback everywhere: Safer locally but breaks container workflows with no override path.

    Plan

    1. Add host variable to justfile top-level, defaulting to 127.0.0.1 via DFT_HOST.
    2. Replace every hardcoded 0.0.0.0 in server recipes with {{host}}.
    3. Update echo messages to use {{host}} for consistency.
    4. Update the README example that shows --host 0.0.0.0.
    5. Leave Procfile unchanged (deployment context).
    6. Validate with just --evaluate and task validate.

    Implementation Progress

    • [x] Audit justfile recipes for 0.0.0.0 bindings (12 recipes found).
    • [x] Add host variable with DFT_HOST env override.
    • [x] Replace all 0.0.0.0 in recipes and echo messages with {{host}}.
    • [x] Update README example.
    • [x] Validate justfile parses and task file is well-formed.

    Review Feedback

    • 2026-03-26: Updated serve and worktree-serve echo output to use {{host}} so DFT_HOST=0.0.0.0 no longer prints misleading loopback URLs for those services.
    • 2026-03-26: Kept the README --host 0.0.0.0 example, but clarified that it is an explicit override for network access rather than the default behavior.
    • 2026-03-26: Documented that the Tasks service remains loopback-only, so its serve/worktree-serve URLs intentionally stay on 127.0.0.1.
    • [x] Review cleared